| Age | Commit message (Collapse) | Author |
|---|
|
Add support for .NET 6
|
|
|
|
|
|
Report exit code when shutting down toolkit
|
|
That's required for Xamarin.Mac, since it needs to call
exit(code) to report the code
|
|
Remove a reference to Xwt.Gtk.
|
|
|
|
Fix Xwt.Mac dll name
|
|
|
|
Add some more markers where ExitCode should be set to non-zero
|
|
|
|
Running GuiUnit under .NET 6 causes test assembly dependencies not
to be resolved even though a parent process has already called
Assembly.LoadFrom. It seems that a call to LoadFile for the assembly
results in dependencies not being resolved. Switch to LoadFrom which
will resolve dependencies.
|
|
No way to currently run tests that require a UI main loop
with XWT or Xamarin.Mac on .NET 6. Added a temporary hack
that adds a console based main loop, using a queue, and
also registers a SynchronisationContext with the same loop
with MonoDevelop.Core.Runtime. This prevents tests in
MonoDevelop.Core hanging waiting for tasks to complete
on the UI thread.
|
|
The XwtMainLoopIntegration was looking for the Xwt.MacEngine in
the wrong dll (Xwt.Mac.dll) and the wrong assembly (Xwt.Mac).
Updated the dll name (Xwt.XamMac.dll) and the assembly name
(Xwt.XamMac).
|
|
|
|
Printing just the test name is confusing, because there can be multiple tests
with the same name.
|
|
This way I don't have to scroll over a potentially large list of tests that
weren't run to find the tests I'm interested in.
|
|
Just ignore obj directories in general
|
|
|
|
|
|
This will be required once Xamarin.Mac starts using mono/2018-08.
|
|
This caused a weird issue where we had the following:
Most of the MD assemblies built against GuiUnit.
MonoDevelop.MonoDroid.Tests built against GuiUnit-Ng.
Since we switched to test deployment, GuiUnit seemed to be the last one
being copied.
Thus, the Android tests would fail to load:
```
2018-08-02T08:55:18.2470490Z Can't find custom attr constructor image: /Users/vsts/agent/2.138.4/work/r1/a/VS for Mac/drop/tests/MonoDevelop.MonoDroid.Tests.dll mtoken: 0x0a000008 due to: Could not resolve type with token 01000013 (from typeref, class/assembly NUnit.Framework.OneTimeTearDownAttribute, GuiUnit, Version=1.0.6397.19727, Culture=neutral, PublicKeyToken=8ebbaf189675e490) assembly:GuiUnit, Version=1.0.6397.19727, Culture=neutral, PublicKeyToken=8ebbaf189675e490 type:NUnit.Framework.OneTimeTearDownAttribute member:(null) signature:<none>
2018-08-02T08:55:18.2513870Z System.TypeLoadException: Could not resolve type with token 01000013 (from typeref, class/assembly NUnit.Framework.OneTimeTearDownAttribute, GuiUnit, Version=1.0.6397.19727, Culture=neutral, PublicKeyToken=8ebbaf189675e490)
2018-08-02T08:55:18.2534360Z at (wrapper managed-to-native) System.MonoCustomAttrs.IsDefinedInternal(System.Reflection.ICustomAttributeProvider,System.Type)
2018-08-02T08:55:18.2557740Z at System.MonoCustomAttrs.IsDefined (System.Reflection.ICustomAttributeProvider obj, System.Type attributeType, System.Boolean inherit) [0x00027] in /Users/builder/jenkins/workspace/build-package-osx-mono/2018-02/external/bockbuild/builds/mono-x64/mcs/class/corlib/System/MonoCustomAttrs.cs:317
2018-08-02T08:55:18.2581720Z at System.Reflection.MonoMethod.IsDefined (System.Type attributeType, System.Boolean inherit) [0x00000] in /Users/builder/jenkins/workspace/build-package-osx-mono/2018-02/external/bockbuild/builds/mono-x64/mcs/class/corlib/System.Reflection/MonoMethod.cs:386
2018-08-02T08:55:18.2605460Z at NUnit.Framework.Internal.Reflect.GetMethodsWithAttribute (System.Type fixtureType, System.Type attributeType, System.Boolean inherit) [0x0001a] in /Users/vsts/agent/2.138.4/work/1/s/md-addins/external/guiunit/src/framework/Internal/Reflect.cs:71
2018-08-02T08:55:18.2628860Z at NUnit.Framework.Internal.TestFixture..ctor (System.Type fixtureType, System.Object[] arguments) [0x00008] in /Users/vsts/agent/2.138.4/work/1/s/md-addins/external/guiunit/src/framework/Internal/Tests/TestFixture.cs:53
2018-08-02T08:55:18.2653880Z at NUnit.Framework.Builders.NUnitTestFixtureBuilder.BuildSingleFixture (System.Type type, NUnit.Framework.TestFixtureAttribute attr) [0x00033] in /Users/vsts/agent/2.138.4/work/1/s/md-addins/external/guiunit/src/framework/Internal/Builders/NUnitTestFixtureBuilder.cs:160
2018-08-02T08:55:18.2677470Z at NUnit.Framework.Builders.NUnitTestFixtureBuilder.BuildFrom (System.Type type) [0x00038] in /Users/vsts/agent/2.138.4/work/1/s/md-addins/external/guiunit/src/framework/Internal/Builders/NUnitTestFixtureBuilder.cs:110
2018-08-02T08:55:18.2700470Z at NUnit.Framework.Internal.TestFixtureBuilder.BuildFrom (System.Type type) [0x00000] in /Users/vsts/agent/2.138.4/work/1/s/md-addins/external/guiunit/src/framework/Internal/TestFixtureBuilder.cs:65
2018-08-02T08:55:18.2724530Z at NUnit.Framework.Internal.NUnitLiteTestAssemblyBuilder.GetFixtures (System.Reflection.Assembly assembly, System.Collections.IList names) [0x0002a] in /Users/vsts/agent/2.138.4/work/1/s/md-addins/external/guiunit/src/framework/Internal/NUnitLiteTestAssemblyBuilder.cs:110
2018-08-02T08:55:18.2748530Z at NUnit.Framework.Internal.NUnitLiteTestAssemblyBuilder.Build (System.Reflection.Assembly assembly, System.Collections.IDictionary options) [0x00018] in /Users/vsts/agent/2.138.4/work/1/s/md-addins/external/guiunit/src/framework/Internal/NUnitLiteTestAssemblyBuilder.cs:52
2018-08-02T08:55:18.2772390Z at NUnit.Framework.Internal.NUnitLiteTestAssemblyRunner.Load (System.Reflection.Assembly assembly, System.Collections.IDictionary settings) [0x00007] in /Users/vsts/agent/2.138.4/work/1/s/md-addins/external/guiunit/src/framework/Internal/NUnitLiteTestAssemblyRunner.cs:96
2018-08-02T08:55:18.2795930Z at GuiUnit.TestRunner.ExecuteWithListener (System.String[] args, NUnitLite.Runner.TcpWriter tcpWriter) [0x0016f] in /Users/vsts/agent/2.138.4/work/1/s/md-addins/external/guiunit/src/framework/GuiUnit/TestRunner.cs:188
```
Since GuiUnit did not report exit code failure for any exception in the harness,
most of the shell scripts which would verify the exit code would just continue
and consider the test run successful.
In case of any exception other than FileNotFoundException, we return 1 as exit code.
Fixes VSTS 657366 - CI does not fail if the test runner fails to run
|
|
Fix docs warnings
|
|
|
|
Fix build warnings
|
|
|
|
|
|
On linux/macOS the exit code is byte-sized, which means that if 256 tests
fails, the exit code would become 0.
|
|
|
|
|
|
This reverts commit f1b9f939acdd72bf481eb5697fd9838fd1ba2464.
This didn't help, so let's just try to fix the actual problem
|
|
If we allow the finalizers to run we may end up returning
a failure exit code if the finalizer does something wrong.
For example xamarin.mac can crash while finalizing CALayers
but we do not really want that to mark our test run as failed.
2017-02-27T02:37:28.1153580Z stderr: Unhandled Exception:
2017-02-27T02:37:28.1186210Z stderr: System.Exception: Failed to marshal the Objective-C object 0x7f85edb651e0 (type: Xamarin_Designer_Mac_DesignerDragOperationMac_MacDragImage_LayerScaleTransitionDelegate). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'Xamarin.Designer.Mac.DesignerDragOperationMac+MacDragImage+LayerScaleTransitionDelegate' does not have a constructor that takes one IntPtr argument).
2017-02-27T02:37:28.1204140Z stderr: at ObjCRuntime.Runtime.MissingCtor (System.IntPtr ptr, System.IntPtr klass, System.Type type, ObjCRuntime.Runtime+MissingCtorResolution resolution) [0x0006e] in <fc5e1fa5f40e47b7ab6a305f19513423>:0
2017-02-27T02:37:28.1218240Z stderr: at ObjCRuntime.Runtime.ConstructNSObject[T] (System.IntPtr ptr, System.Type type, ObjCRuntime.Runtime+MissingCtorResolution missingCtorResolution) [0x0002c] in <fc5e1fa5f40e47b7ab6a305f19513423>:0
2017-02-27T02:37:28.1232350Z stderr: at ObjCRuntime.Runtime.ConstructNSObject (System.IntPtr ptr, System.IntPtr klass, ObjCRuntime.Runtime+MissingCtorResolution missingCtorResolution) [0x00015] in <fc5e1fa5f40e47b7ab6a305f19513423>:0
2017-02-27T02:37:28.1246740Z stderr: at ObjCRuntime.Runtime.GetNSObject (System.IntPtr ptr, ObjCRuntime.Runtime+MissingCtorResolution missingCtorResolution, System.Boolean evenInFinalizerQueue) [0x00034] in <fc5e1fa5f40e47b7ab6a305f19513423>:0
2017-02-27T02:37:28.1260580Z stderr: at Registrar.DynamicRegistrar.GetMethodDescriptionAndObject (System.Type type, System.IntPtr selector, System.IntPtr obj, System.IntPtr& mthis) [0x00068] in <fc5e1fa5f40e47b7ab6a305f19513423>:0
2017-02-27T02:37:28.1274350Z stderr: at ObjCRuntime.Runtime.GetMethodAndObjectForSelector (System.IntPtr klass, System.IntPtr sel, System.IntPtr obj, System.IntPtr& mthis) [0x0000c] in <fc5e1fa5f40e47b7ab6a305f19513423>:0
2017-02-27T02:37:28.1289980Z stderr: at ObjCRuntime.Runtime.get_method_and_object_for_selector (System.IntPtr cls, System.IntPtr sel, System.IntPtr obj, System.IntPtr& mthis, System.Int32& exception_gchandle) [0x00006] in <fc5e1fa5f40e47b7ab6a305f19513423>:0
2017-02-27T02:37:28.1313850Z stderr: --- End of stack trace from previous location where exception was thrown ---
2017-02-27T02:37:28.1331490Z stderr: at (wrapper managed-to-native) ObjCRuntime.Messaging:void_objc_msgSend_IntPtr (intptr,intptr,intptr)
2017-02-27T02:37:28.1345900Z stderr: at CoreAnimation.CALayer.set_WeakDelegate (Foundation.NSObject value) [0x0002e] in <fc5e1fa5f40e47b7ab6a305f19513423>:0
2017-02-27T02:37:28.1358800Z stderr: at CoreAnimation.CALayer.OnDispose () [0x00024] in <fc5e1fa5f40e47b7ab6a305f19513423>:0
2017-02-27T02:37:28.1371610Z stderr: at CoreAnimation.CALayer.Dispose (System.Boolean disposing) [0x00001] in <fc5e1fa5f40e47b7ab6a305f19513423>:0
2017-02-27T02:37:28.1384350Z stderr: at Foundation.NSObject.Finalize () [0x00001] in <fc5e1fa5f40e47b7ab6a305f19513423>:0
|
|
|
|
|
|
Works around https://bugzilla.xamarin.com/show_bug.cgi?id=43932
|
|
|
|
The calling assembly will always be guiunit itself. All our
tests are written in different assembly. As such, if we aren't
given the path to an assembly we should assume that something else
is loading us and the thing which loaded us has the tests.
|
|
|
|
This allows custom main loop integrations to use it when
Shutdown is called in the case where the integration's
IMainLoopIntegration.RunMainLoop is a no-op (e.g. the
main loop is running already).
|
|
|
|
|
|
|
|
Such a hack :)
|
|
|
|
|
|
|
|
We're more than happy with a single static variable. We don't support
multiple appdomains (or want to support it), and our usage of
async/await does not work with CallContext under .NET 4.5. We end up
getting a null value from CallContext.GetData after an await
completes, which is expected behaviour.
|
|
|
|
The actul bug was that Xamarin Studio was incorrectly specifying
the test name. This has been fixed now.
|
|
Fix two wrong conditionals.
|
