* [xibuild] Add support for /verbose, and use it accordingly.
Also stop using xibuild when it's not needed.
* Use the same verbosity for xibuild as we do for xbuild/msbuild.
Fixes this problem when running the VSTS device tests:
Unhandled Exception:
System.Collections.Generic.KeyNotFoundException: The given key 'MONO_SDK_DESTDIR' was not present in the dictionary.
at System.Collections.Generic.Dictionary`2[TKey,TValue].get_Item (TKey key) [0x0001e] in <96207d0baa204f48a53ad6be05f5ecba>:0
at xharness.Harness.LoadConfig () [0x001a3] in <299e29e4a95f41499aef8f7d9863ca3d>:0
at xharness.Harness.Execute () [0x00001] in <299e29e4a95f41499aef8f7d9863ca3d>:0
at xharness.MainClass.Main (System.String[] args) [0x003e3] in <299e29e4a95f41499aef8f7d9863ca3d>:0
including
* Reflection is simply not needed. Existing unit tests
confirms the virtual method are called properly.
* Reduce metadata
* reuse internal delegate types using identical signatures
* remove internnal enum with a single value
* Use `nint` (for `CFIndex`) so it's clearly 64 bits aware (not just
trusting alignment rules)
reference: https://github.com/xamarin/xamarin-macios/issues/5303
* [tests] Add test to ensure LLVM succeeds on watchOS for every assembly we ship.
References:
* https://github.com/mono/mono/issues/12131: LLVM failed for 'UIEdgeInsets.Equals': opcode r4_cneq
* https://github.com/mono/mono/issues/12130: [watchOS] MT3001: Could not AOT the assembly mscorlib.dll
* https://github.com/xamarin/xamarin-macios/issues/4763: [RFC] Improve handling of filter clauses with LLVM/Bitcode
* https://bugzilla.xamarin.com/show_bug.cgi?id=58209: LLVM/bitcode can't handle filter clauses
* LLVM failure in mscorlib.dll is now fixed.
* Revert "LLVM failure in mscorlib.dll is now fixed."
This reverts commit ace3c930a9.
* [tests] Run mtouch tests inprocess.
Fixes a remoting exception:
System.Runtime.Remoting.RemotingException: Cannot create channel sink to connect to URL fff8ce5c_3219_4dd0_941f_500dd49e02a5/94f23f2_4.rem. An appropriate channel has probably not been registered.
Server stack trace:
at System.Runtime.Remoting.RemotingServices.GetClientChannelSinkChain (System.String url, System.Object channelData, System.String& objectUri) [0x00019] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.RemotingServices.GetOrCreateClientIdentity (System.Runtime.Remoting.ObjRef objRef, System.Type proxyType, System.Object& clientProxy) [0x0001d] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.RemotingServices.GetRemoteObject (System.Runtime.Remoting.ObjRef objRef, System.Type proxyType) [0x00000] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.RemotingServices.GetProxyForRemoteObject (System.Runtime.Remoting.ObjRef objref, System.Type classToProxy) [0x0001b] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef objectRef, System.Boolean fRefine) [0x0007a] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef objectRef) [0x00000] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.ObjRef.GetRealObject (System.Runtime.Serialization.StreamingContext context) [0x0000f] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Serialization.ObjectManager.ResolveObjectReference (System.Runtime.Serialization.ObjectHolder holder) [0x00010] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Serialization.ObjectManager.DoFixups () [0x0007f] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize (System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Runtime.Serialization.Formatters.Binary.__BinaryParser serParser, System.Boolean fCheck, System.Boolean isCrossAppDomain, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00077] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Boolean fCheck, System.Boolean isCrossAppDomain, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x000a2] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Boolean fCheck, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00000] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.DeserializeMethodResponse (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00000] in <96207d0baa204f48a53ad6be05f5ecba>:0
at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage msg) [0x00083] in <dcf627861d9e44ce818b79d685496eeb>:0
Exception rethrown at [0]:
at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_remoting_wrapper(intptr,intptr)
at (wrapper remoting-invoke) NUnit.Engine.Agents.RemoteTestAgent.Load()
at NUnit.Engine.Runners.ProcessRunner.LoadPackage () [0x00040] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
at NUnit.Engine.Runners.AbstractTestRunner.Load () [0x00000] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
at NUnit.Engine.Runners.MasterTestRunner.LoadPackage () [0x0006b] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
at NUnit.Engine.Runners.MasterTestRunner..ctor (NUnit.Engine.IServiceLocator services, NUnit.Engine.TestPackage package) [0x0007a] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
at NUnit.Engine.TestEngine.GetRunner (NUnit.Engine.TestPackage package) [0x0001e] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
at NUnit.ConsoleRunner.ConsoleRunner.RunTests (NUnit.Engine.TestPackage package, NUnit.Engine.TestFilter filter) [0x00095] in <93782c327b3c4ab5aae551528dfe1cae>:0
at NUnit.ConsoleRunner.ConsoleRunner.Execute () [0x000b6] in <93782c327b3c4ab5aae551528dfe1cae>:0
at NUnit.ConsoleRunner.Program.Main (System.String[] args) [0x001b5] in <93782c327b3c4ab5aae551528dfe1cae>:0
* [xharness] Run mtouch tests in-process.
* [tests] Don't run the LLVM watchOS tests if we didn't build for device.
* [tests] Update NoLLVMFailuresInWatchOS known failures according to latest mono bump.
Also run 'make bgen' after the build to install any newly built binaries, so
that the generator tests that don't use the in-proc generator automatically
pick up the newly built one.
Even if 'supportedVideoFormats' is static the type is abstract.
> Important
> ARConfiguration is an abstract base class, so its implementation of
> this property always returns an empty array. Read this property from
> the configuration subclass you plan to use for your AR session, such
> as ARWorldTrackingConfiguration or ARFaceTrackingConfiguration.
https://developer.apple.com/documentation/arkit/arconfiguration/2942261-supportedvideoformats?language=objc
and this behave differently in Objective-C (than .net) as every (static)
method will be different (and not a single implementation like C#).
The existing implementation (as a property) calls `ARConfiguration`
implementation which simply throws a (native) exception
> NSInvalidArgumentException Reason: Supported video formats should be called on individual configuration class
The solution is to obsolete the property (can't be subclassed in .net
since it's static) and add, only on the subclasses, a method that
call the 'supportedVideoFormats' selector on the current (not base)
type.
Added unit test to detect the addition of newer subclasses - since they
will also need to expose this method.
reference: https://github.com/xamarin/xamarin-macios/issues/5347
Basic fix that does not require a breaking change.
It's _basic_ as it does not fix the performance comments made inside
the issue. Those are different (not a bug, an enhancement) and I'll
file a separate issue to track this.
Reference: https://github.com/xamarin/xamarin-macios/issues/5132
This PR adds support to the use of *.ignore files for iOS/tvOS/WatchOS. The files are very similar to those that are use in xtro. We have:
* common-{TestProjectName}.ignore: For those tests that fail in all platforms.
* tvOS-{TestProjectName}.ignore: For tvOS specific failures.
* watchOS-{TestProjectName}.ignore: For watchOS specific failures.
* iOS-{TestProjectName}.ignore: for iOS specific projects.
Two test projects that were ignored previously have been added to show that the code does as advertised:
* SystemDataXunit: xUnit test project example. Fixes https://github.com/xamarin/maccore/issues/1131
* SystemServiceModelWebTests: NUnit test project example. Fixes https://github.com/xamarin/maccore/issues/1137
The files take the name of the failing tests, although we do support ignoring by class/namespace and other combinations, that would make the *.ignore files format more complicated and it is not worth it.
objc_msgSend*_stret doesn't exist on arm64, so trying to call these functions
in our generated P/Invoke wrappers will result in a clang error:
[...]/pinvokes.m:180:69: error: 'objc_msgSend_stret' is unavailable: not available in arm64 (TaskId:243)
So instead generate a call to throw an EntryPointNotFoundException (which is
exactly what would happen if we didn't generate the P/Invoke wrapper).
Fixes https://github.com/xamarin/xamarin-macios/issues/5183.
Only the arm64 slice are built for iOS 7.0 (because that's when arm64 was
introduced), the arm7(s) slices are built for iOS 6.0, which means it's safe
to ignore this warning.
Fixes https://github.com/xamarin/xamarin-macios/issues/5092.
Hopefully fixes these tests:
Xamarin.iOS.Tasks.TargetTests.RebuildLibrary_TouchBundleResource: Expected: not 2018-12-18 17:15:05.000
But was: 2018-12-18 17:15:05.000
Xamarin.iOS.Tasks.TargetTests.RebuildLibrary_TouchEmbeddedResource: Expected: not 2018-12-18 17:15:07.000
But was: 2018-12-18 17:15:07.000
Xamarin.iOS.Tasks.TargetTests.RebuildLibrary_TouchStoryboard: Expected: not 2018-12-18 17:15:09.000
But was: 2018-12-18 17:15:09.000
Additionally change existing sleeping code to not sleep when running on APFS.
Should make test runs slightly faster.
* [runtime] Only print the stack trace if we have a stack trace.
* [runtime] Only print 'Unhandled managed exception' when it's actually an unhandled exception.
We render exceptions in several other circumstances, when they're not
unhandled, so this improves the output text in those scenarios a little bit.
* [runtime] Fix typo in logging message.
* [runtime] Improve abort message for managed exception marshalling a bit.
Fixes these test failure:
Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").FrameworksEmbeddedProperly(True): #RunTarget-ErrorCount
linker command failed with exit code 1 (use -v to see invocation)
Native linking failed, undefined Objective-C class: MDLTransform. The symbol '_OBJC_CLASS_$_MDLTransform' could not be found in any of the libraries or frameworks linked with your application.
Native linking failed. Please review the build log.
Expected: 0
But was: 3
Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").ShouldNotUnnecessarilyRebuildFinalProject(True): #RunTarget-ErrorCount
linker command failed with exit code 1 (use -v to see invocation)
Native linking failed, undefined Objective-C class: MDLTransform. The symbol '_OBJC_CLASS_$_MDLTransform' could not be found in any of the libraries or frameworks linked with your application.
Native linking failed. Please review the build log.
Expected: 0
But was: 3
This makes Visual Studio for Mac show a better error message when the system mono is too old:
FATAL ERROR [2018-12-19 08:07:50Z]: Visual Studio failed to start. Some of the assemblies required to run Visual Studio (for example gtk-sharp)may not be properly installed in the GAC.
System.Exception: Toolkit could not be loaded ---> System.NotSupportedException: This version of Xamarin.Mac requires Mono 5.18.0.185, but found Mono 5.16.0.209.
at ObjCRuntime.Runtime.VerifyMonoVersion () [0x000b4] in /work/maccore/master/xamarin-macios/src/ObjCRuntime/Runtime.mac.cs:150
at ObjCRuntime.Runtime.EnsureInitialized () [0x00030] in /work/maccore/master/xamarin-macios/src/ObjCRuntime/Runtime.mac.cs:117
at AppKit.NSApplication.Init () [0x00016] in /work/maccore/master/xamarin-macios/src/AppKit/NSApplication.cs:56
at Xwt.Mac.NSApplicationInitializer.Initialize () [0x00051] in /work/monodevelop/monodevelop/main/external/xwt/Xwt.XamMac/Xwt.Mac/NSApplicationInitializer.cs:44
at Xwt.Mac.MacEngine.InitializeApplication () [0x00001] in /work/monodevelop/monodevelop/main/external/xwt/Xwt.XamMac/Xwt.Mac/MacEngine.cs:48
instead of (from https://github.com/mono/monodevelop/issues/6779):
FATAL ERROR [2018-12-17 14:05:44Z]: Visual Studio failed to start. Some of the assemblies required to run Visual Studio (for example gtk-sharp)may not be properly installed in the GAC.
System.Exception: Toolkit could not be loaded ---> System.NullReferenceException: Object reference not set to an instance of an object
at (wrapper managed-to-native) System.Object.wrapper_native_0x102f47470()
at ObjCRuntime.Runtime.EnsureInitialized () [0x00041] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.6.0.1/src/Xamarin.Mac/ObjCRuntime/Runtime.mac.cs:118
at AppKit.NSApplication.Init () [0x00016] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.6.0.1/src/Xamarin.Mac/AppKit/NSApplication.cs:56
at Xwt.Mac.NSApplicationInitializer.Initialize () [0x00046] in /Users/vsts/agent/2.144.0/work/1/s/monodevelop/main/external/xwt/Xwt.XamMac/Xwt.Mac/NSApplicationInitializer.cs:44
at Xwt.Mac.MacEngine.InitializeApplication () [0x00000] in /Users/vsts/agent/2.144.0/work/1/s/monodevelop/main/external/xwt/Xwt.XamMac/Xwt.Mac/MacEngine.cs:48
When `HttpClient` is used it might not be possible to set custom
properties on the handler.
This PR avoids a fight between the `HttpClient.Timeout` and the ones that
`NSURLSession` provides - making its use, as default, working as expected
It is still possible to set those custom properties when creating the
`NSUrlSessionHandler` manually, so there's no loss of functionalities.
Adding a unit test would be tricky since it depends on external sites and
requires "enough" delays to trigger (both leading to false positives over
time).
Notes
* HttpClientHandler timeout is broken -> https://github.com/mono/mono/issues/12100
* CFNetworkHandler is broken when no data is received -> https://github.com/xamarin/xamarin-macios/issues/5289
Fixes https://github.com/xamarin/xamarin-macios/issues/5190
* [msbuild] Adds output property for unpacked resources
This output property will be used by VS to create/touch output files on Windows only for the unpacked resources and not for all the resources found.
Partial fix for bug 662636 - *.dylib libraries are signed during full rebuild, but not the second time
https://devdiv.visualstudio.com/DevDiv/_queries/edit/662636
* [msbuild] Adds output property with copied frameworks to MTouchTaskBase
This property is needed from VS to know Frameworks where changed as a result of the mtouch execution. The lack of this information was causing MSBuild to skip the CodesignFrameworks target (from Windows) on incremental builds if the frameworks were copied to the app bundle by mtouch.
Partial fix for bug 662636 - *.dylib libraries are signed during full rebuild, but not the second time
https://devdiv.visualstudio.com/DevDiv/_queries/edit/662636
We now download the ios Mono sdk which means that there is no need for
us to build the test assemblies on iOS, WatchOS and tvOS BUT we need to
do so for the Mac tests.
The change includes:
1. Use fo the downloaded test assemblies.
2. Removal of the dependency of building them in the tests.
3. Move back to using reflection for the project generation.
4. Remove the cached project details added in the workaround.
* [builds] Consume LLVM from mono's package.
* Fix mono sdk paths in makefile to be relative to the top.
* [builds] Make curl verbose if V=1.
* [builds] Improve llvm build targets.
* Fix dependencies so that 'make -j llvm' (and other variations of the same
target) work properly.
* Rename things a bit to make it clear there are 32-bit and 64-bit llvm
targets.
* [builds] Consume cross compilers from mono's package as well.
Compiling the cross compilers while using LLVM from mono's package becomes
complicated, so just go ahead and get the cross compilers from the mono
package as well.
* Make llvm rules symmetric between llvm32 and llvm64.
The MessageHandler class suffers from the CVE 2018-8292. this commit
fixes the issue by ensuring that the we donot use autoredirect from
CFNetwork and perform the first request. If the response is a redirect,
follow it wihout the Autherization headers.
First step to get to the point in which we can filter the execution of
the bcl tests via filters. This commit adds the filtering support to the
runners, which later will be used by xharness to pass those tests
filtered.
The end goal is to not skip a complete assembly but just those failing
tests.
- Existing binding projects embed the native libraries within the assembly as managed resource
- This does not scale well and has performance implications
- This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently.
- Existing binding projects are not affected, they will continue as is
- I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects.
-When we complete some form of msbuild testing reform, we'll revisit these tests.
- Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere)
- Remove unnecessary sleep and fix broken touch command
- Output failing test log to console instead of test output
- VSfM does not handle thousands of lines of test failure message well
- Add ability to generate binding projects with LinkWith
This change adds support to execute the tests provided by mono as assemblies.This includes:
1. App generation to run the bcl tests on modern and full.
2. Needed workaround to delay the compilation of the assemblies until we have them from the SDK.
3. All failing tests are ignored.
Sebastien Pouliot
Rolf Bjarne Kvinge
Emanuel Fernandez Dell'Oca
Cody Russell
Manuel de la Pena
Filip Navara
Matt Sylvia
Chris Hamons
Bernhard Urban
Matt Sylvia