[xharness] Get new mlaunch for beta 4. #1

rolfbjarne · 2016-08-02T16:18:28Z

No description provided.

…tentially other framework assemblies) Target _UnpackLibraryResources: Task "UnpackLibraryResources" Using task UnpackLibraryResources from Xamarin.MacDev.Tasks.UnpackLibraryResources, Xamarin.MacDev.Tasks, Version=1.0.6128.15885, Culture=neutral, PublicKeyToken=null UnpackLibraryResources Task Prefix: monotouch IntermediateOutputPath: obj/iPhone/Debug/ NoOverwrite: obj/iPhone/Debug/ibtool-link/LaunchScreen.storyboardc/01J-lp-oVM-view-Ze5-6b-2t3.nib obj/iPhone/Debug/ibtool-link/LaunchScreen.storyboardc/Info.plist obj/iPhone/Debug/ibtool-link/LaunchScreen.storyboardc/UIViewController-01J-lp-oVM.nib obj/iPhone/Debug/ibtool-link/Main.storyboardc/BYZ-38-t0r-view-8bC-Xf-vdC.nib obj/iPhone/Debug/ibtool-link/Main.storyboardc/Info.plist obj/iPhone/Debug/ibtool-link/Main.storyboardc/UIViewController-BYZ-38-t0r.nib ReferencedLibraries: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.dll /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Xml.dll /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Core.dll /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/Xamarin.iOS.dll /Users/poupou/Downloads/LinkingTest-2/RMSDKWrapper/bin/Debug//RMSDKWrapper.dll /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS//mscorlib.dll /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS//mscorlib.dll Skipping framework assembly: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.dll Skipping framework assembly: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Xml.dll Skipping framework assembly: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Core.dll Skipping framework assembly: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/Xamarin.iOS.dll Inspecting assembly: /Users/poupou/Downloads/LinkingTest-2/RMSDKWrapper/bin/Debug//RMSDKWrapper.dll Inspecting assembly: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS//mscorlib.dll Inspecting assembly: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS//mscorlib.dll Done executing task "UnpackLibraryResources" Done building target "_UnpackLibraryResources" in project "/Users/poupou/Downloads/LinkingTest-2/LinkingTest/LinkingTest.csproj". The above log excerpt shows two issues: 1. mscorlib.dll is needlessly inspected as it's **not** considered a "framework" assembly. The current check was checking *how* it was resolved and not *where* it was resolved to. The later is the most important as it's possible for other assemblies to have direct paths references and we do not want to process them. This is fixed by comparing each assembly path with the (now) provided `TargetFrameworkDirectory` 2. mscorlib.dll is inspected twice That's because it's present two times in the task's input. That issue is upstream (not sure why) of the current task but it makes #1 twice as costly. The fix for #1 indirectly fix that too. Future ------ It's worth investigating to move that logic into `mtouch`. The later must already load all assemblies and is in charge of removing other embedded data (e.g. native code from bindings) from the assemblies (so they are not shipped both inside and outside the .dll in the final .app). This makes this task seems extraneous work. Considering that my current test case, `RMSDKWrapper.dll`, is 1.3GB in size it's easy to see that the extra load (which has nothing to be extracted wrt resources*) is quite visible in build time. > 3268.201 ms UnpackLibraryResources 1 calls * it has for bindings but that's already handled by mtouch

* [msbuild] Don't rewrite embedded.mobileprovision or archived-expanded-entitlements.xcent This patch prevents those 2 files from being rewritten in cases where the contents would not change from what was already there previously. This is a partial fix for https://bugzilla.xamarin.com/show_bug.cgi?id=49097 * [msbuild] Re-enabled the RebuildExecutable_NoModifications unit test With the fixes to EmbedProvisioningProfile and CompileEntitlements, this unit test now passes.

…tentially other framework assemblies) (dotnet#1011) Target _UnpackLibraryResources: Task "UnpackLibraryResources" Using task UnpackLibraryResources from Xamarin.MacDev.Tasks.UnpackLibraryResources, Xamarin.MacDev.Tasks, Version=1.0.6128.15885, Culture=neutral, PublicKeyToken=null UnpackLibraryResources Task Prefix: monotouch IntermediateOutputPath: obj/iPhone/Debug/ NoOverwrite: obj/iPhone/Debug/ibtool-link/LaunchScreen.storyboardc/01J-lp-oVM-view-Ze5-6b-2t3.nib obj/iPhone/Debug/ibtool-link/LaunchScreen.storyboardc/Info.plist obj/iPhone/Debug/ibtool-link/LaunchScreen.storyboardc/UIViewController-01J-lp-oVM.nib obj/iPhone/Debug/ibtool-link/Main.storyboardc/BYZ-38-t0r-view-8bC-Xf-vdC.nib obj/iPhone/Debug/ibtool-link/Main.storyboardc/Info.plist obj/iPhone/Debug/ibtool-link/Main.storyboardc/UIViewController-BYZ-38-t0r.nib ReferencedLibraries: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.dll /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Xml.dll /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Core.dll /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/Xamarin.iOS.dll /Users/poupou/Downloads/LinkingTest-2/RMSDKWrapper/bin/Debug//RMSDKWrapper.dll /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS//mscorlib.dll /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS//mscorlib.dll Skipping framework assembly: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.dll Skipping framework assembly: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Xml.dll Skipping framework assembly: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Core.dll Skipping framework assembly: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/Xamarin.iOS.dll Inspecting assembly: /Users/poupou/Downloads/LinkingTest-2/RMSDKWrapper/bin/Debug//RMSDKWrapper.dll Inspecting assembly: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS//mscorlib.dll Inspecting assembly: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS//mscorlib.dll Done executing task "UnpackLibraryResources" Done building target "_UnpackLibraryResources" in project "/Users/poupou/Downloads/LinkingTest-2/LinkingTest/LinkingTest.csproj". The above log excerpt shows two issues: 1. mscorlib.dll is needlessly inspected as it's **not** considered a "framework" assembly. The current check was checking *how* it was resolved and not *where* it was resolved to. The later is the most important as it's possible for other assemblies to have direct paths references and we do not want to process them. This is fixed by comparing each assembly path with the (now) provided `TargetFrameworkDirectory` 2. mscorlib.dll is inspected twice That's because it's present two times in the task's input. That issue is upstream (not sure why) of the current task but it makes #1 twice as costly. The fix for #1 indirectly fix that too. Future ------ It's worth investigating to move that logic into `mtouch`. The later must already load all assemblies and is in charge of removing other embedded data (e.g. native code from bindings) from the assemblies (so they are not shipped both inside and outside the .dll in the final .app). This makes this task seems extraneous work. Considering that my current test case, `RMSDKWrapper.dll`, is 1.3GB in size it's easy to see that the extra load (which has nothing to be extracted wrt resources*) is quite visible in build time. > 3268.201 ms UnpackLibraryResources 1 calls * it has for bindings but that's already handled by mtouch

TL&DR: This is *how* it should be done and tested, it's not complete (single, simple case) nor the most interesting case ;-) The trick is to make sure each case is covered by tests so a mono _bump_ won't give us a BCL that does not conform to what the linker expect. What's the impact ? 1. There is the expected reduction of metadata in mscorlib. Since both methods don't call other API there's no indirect effect (removal). --- before 2017-01-15 11:12:44.000000000 -0500 +++ after 2017-01-15 11:12:56.000000000 -0500 @@ -13166,9 +13166,6 @@ System.Void System.Security.SecurityException::.ctor(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext) System.Void System.Security.SecurityException::.ctor(System.String) System.Void System.Security.SecurityException::GetObjectData(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext) -System.Boolean System.Security.SecurityManager::CheckElevatedPermissions() -System.Security.SecurityManager -System.Void System.Security.SecurityManager::EnsureElevatedPermissions() System.Security.SecurityRulesAttribute System.Security.SecurityRuleSet System.Security.SecurityRulesAttribute::m_ruleSet System.Void System.Security.SecurityRulesAttribute::.ctor(System.Security.SecurityRuleSet) 2. There is no visible size change (even with #1) in mscorlib.dll due to padding (compiler /filealign) mscorlib.dll 793,600 793,600 0 0.00 % 3. there's a *very* small reduction of mscorlib.*.aotdata size mscorlib.armv7.aotdata 717,264 717,216 -48 -0.01 % mscorlib.arm64.aotdata 712,840 712,704 -136 -0.02 % AOT data *.aotdata 6,460,064 6,459,880 -184 0.00 % 4. there's no change in executable size - normal as the AOT compiler has _likely_ already doing the same optimization (before this commit) Executable 29,270,272 29,270,272 0 0.00 % Full comparison: https://gist.github.com/spouliot/0464c8fa3a92b6486dfd90595d9eb718

…dotnet#1513) TL&DR: This is *how* it should be done and tested, it's not complete (single, simple case) nor the most interesting case ;-) The trick is to make sure each case is covered by tests so a mono _bump_ won't give us a BCL that does not conform to what the linker expect. What's the impact ? 1. There is the expected reduction of metadata in mscorlib. Since both methods don't call other API there's no indirect effect (removal). --- before 2017-01-15 11:12:44.000000000 -0500 +++ after 2017-01-15 11:12:56.000000000 -0500 @@ -13166,9 +13166,6 @@ System.Void System.Security.SecurityException::.ctor(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext) System.Void System.Security.SecurityException::.ctor(System.String) System.Void System.Security.SecurityException::GetObjectData(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext) -System.Boolean System.Security.SecurityManager::CheckElevatedPermissions() -System.Security.SecurityManager -System.Void System.Security.SecurityManager::EnsureElevatedPermissions() System.Security.SecurityRulesAttribute System.Security.SecurityRuleSet System.Security.SecurityRulesAttribute::m_ruleSet System.Void System.Security.SecurityRulesAttribute::.ctor(System.Security.SecurityRuleSet) 2. There is no visible size change (even with #1) in mscorlib.dll due to padding (compiler /filealign) mscorlib.dll 793,600 793,600 0 0.00 % 3. there's a *very* small reduction of mscorlib.*.aotdata size mscorlib.armv7.aotdata 717,264 717,216 -48 -0.01 % mscorlib.arm64.aotdata 712,840 712,704 -136 -0.02 % AOT data *.aotdata 6,460,064 6,459,880 -184 0.00 % 4. there's no change in executable size - normal as the AOT compiler has _likely_ already doing the same optimization (before this commit) Executable 29,270,272 29,270,272 0 0.00 % Full comparison: https://gist.github.com/spouliot/0464c8fa3a92b6486dfd90595d9eb718

…net#2231) Fixes: 1. Failed : Xamarin.MTouch.MT0091(tvOS,"tvOS") The error 'MT0091: This version of Xamarin.iOS requires the tvOS 11.0 SDK (shipped with Xcode 9.0). Either upgrade Xcode to get the required header files or set the managed linker behaviour to Link Framework SDKs Only (to try to avoid the new APIs).' was not found in the output: Message #1 did not match: actual: 'This version of Xamarin.iOS requires the tvOS 11.0 SDK (shipped with Xcode 9). Either upgrade Xcode to get the required header files or set the managed linker behaviour to Link Framework SDKs Only (to try to avoid the new APIs).' expected: 'This version of Xamarin.iOS requires the tvOS 11.0 SDK (shipped with Xcode 9.0). Either upgrade Xcode to get the required header files or set the managed linker behaviour to Link Framework SDKs Only (to try to avoid the new APIs).' 2. Failed : Xamarin.MTouch.MT0091(iOS,"iOS") The error 'MT0091: This version of Xamarin.iOS requires the iOS 11.0 SDK (shipped with Xcode 9.0). Either upgrade Xcode to get the required header files or set the managed linker behaviour to Link Framework SDKs Only (to try to avoid the new APIs).' was not found in the output: Message #1 did not match: actual: 'This version of Xamarin.iOS requires the iOS 11.0 SDK (shipped with Xcode 9). Either upgrade Xcode to get the required header files or set the managed linker behaviour to Link Framework SDKs Only (to try to avoid the new APIs).' expected: 'This version of Xamarin.iOS requires the iOS 11.0 SDK (shipped with Xcode 9.0). Either upgrade Xcode to get the required header files or set the managed linker behaviour to Link Framework SDKs Only (to try to avoid the new APIs).' 3. Failed : Xamarin.Registrar.NoWarnings no warnings Expected: not String matching "warning:" But was: "/Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory298/mtouch-test-cache/registrar.m:32468:17: warning: method 'paymentAuthorizationViewController:didAuthorizePayment:handler:' in protocol 'PKPaymentAuthorizationViewControllerDelegate' not implemented [-Wprotocol]" https://bugzilla.xamarin.com/show_bug.cgi?id=57601

…re. (dotnet#3391) * [linker] Optimize calls to BlockLiteral.SetupBlock to inject the block signature. Optimize calls to BlockLiteral.SetupBlock[Unsafe] to calculate the block signature at build time, and inject it into the call site. This makes block invocations 10-15x faster (I've added tests that asserts at least an 8x increase). It's also required in order to be able to remove the dynamic registrar code in the future (since calculating the block signature at runtime requires the dynamic registrar). * [mtouch/mmp] Add support for reporting errors/warnings that point to the code line causing the error/warning. Add support for reporting errors/warnings that point to the code line causing the error/warning by adding ErrorHelper overloads that take the exact instruction to report (previously we defaulted to the first line/instruction in a method). * [tests] Add support for asserting filename/linenumber in warning messages. * Make all methods that manually create BlockLiterals optimizable. * [tests] Create a BaseOptimizeGeneratedCodeTest test that's included in both XI's and XM's link all test. * [tests] Add link all test (for both XI and XM) to test the BlockLiteral.SetupBlock optimization. * [tests] Add mtouch/mmp tests for the BlockLiteral.SetupBlock optimization. * [tests][linker] Make the base test class abstract, so tests in the base class aren't executed twice. * [tests][linker] Don't execute linkall-only tests in linksdk. The optimization tests only apply when the test assembly is linked, and that only happens in linkall, so exclude those tests in linksdk. * [tests][mmptest] Update test according to mmp changes. Fixes these test failures: 1) Failed : Xamarin.MMP.Tests.MMPTests.MM0132("inline-runtime-arch") The warning 'MM0132: Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.' was not found in the output: Message #1 did not match: actual: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.' expected: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.' Message #2 did not match: actual: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.' expected: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.' 2) Failed : Xamarin.MMP.Tests.MMPTests.MM0132("foo") The warning 'MM0132: Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.' was not found in the output: Message #1 did not match: actual: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.' expected: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.' Message #2 did not match: actual: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.' expected: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.' * [tests][linker] Fix typo. Fixes this test failure: 1) SetupBlock_CustomDelegate (Linker.Shared.BaseOptimizeGeneratedCodeTest.SetupBlock_CustomDelegate) Counter Expected: 1 But was: 2 * [registrar] Minor adjustment to error message to match previous (and better) behavior. Fixes this test failure: 1) Failed : Xamarin.Registrar.GenericType_WithInvalidParameterTypes The error 'MT4136: The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1)'' was not found in the output: Message #1 did not match: actual: 'The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1<Foundation.NSObject>' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1)'' expected: 'The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1)'' * [docs] mmp shows MM errors/warnings. * [docs] Improve according to reviews. * [tests] Fix merge failure causing test duplication.

…rar optimization until after checking the linker settings. (dotnet#3643) (dotnet#3661) Fixes this test failure: 1) Failed : Xamarin.MTouch.MT0113_linker The error 'MT0113: Native code sharing has been disabled for the extension 'testServiceExtension' because the managed linker settings are different between the container app (None) and the extension (All).' was not found in the output: Message #1 did not match: actual: 'Native code sharing has been disabled for the extension 'testServiceExtension' because the remove-dynamic-registrar optimization differ between the container app (default) and the extension (false).' expected: 'Native code sharing has been disabled for the extension 'testServiceExtension' because the managed linker settings are different between the container app (None) and the extension (All).' which happens because: * Removing the dynamic registrar requires the linker, so removal of the dynamic registrar is disabled if the linker is not disabled * This results in the app and appex having different values for the remove-dynamic-registrar option * Thus the error message. Technically either error is correct, but I prefer the previous one (about the linker), because it directly assigns blame (the linker setting). Figuring out what has to change (the linker setting) when the error message complains about an optimization is not so straight forward for users.

…rar optimization until after checking the linker settings. (dotnet#3643) Fixes this test failure: 1) Failed : Xamarin.MTouch.MT0113_linker The error 'MT0113: Native code sharing has been disabled for the extension 'testServiceExtension' because the managed linker settings are different between the container app (None) and the extension (All).' was not found in the output: Message #1 did not match: actual: 'Native code sharing has been disabled for the extension 'testServiceExtension' because the remove-dynamic-registrar optimization differ between the container app (default) and the extension (false).' expected: 'Native code sharing has been disabled for the extension 'testServiceExtension' because the managed linker settings are different between the container app (None) and the extension (All).' which happens because: * Removing the dynamic registrar requires the linker, so removal of the dynamic registrar is disabled if the linker is not disabled * This results in the app and appex having different values for the remove-dynamic-registrar option * Thus the error message. Technically either error is correct, but I prefer the previous one (about the linker), because it directly assigns blame (the linker setting). Figuring out what has to change (the linker setting) when the error message complains about an optimization is not so straight forward for users.

The MSBuild tasks will codesign an executable if the executable's timestamp is later than `_CodeSignature/CodeResources`'s timestamp (or if `_CodeSignature/CodeResources` doesn't exist). Unfortunately, the codesign executable modifies both of those files, and the executable last. This means that even just after running codesign, the executable's timestamp might be later than `_CodeSignature/CodeResources`'s timestamp (due to HFS+'s one-second timestamp resolution, this might happen all within the same second, which means that this is a random issue: the problem only occurs if the executable was modified at least a second later than `_CodeSignature/CodeResources`.) So make sure to touch `_CodeSignature/CodeResources` after running codesign, so that the next time a build occurs (with no modifications), we don't resign needlessly. Fixes this (random) test failure when running the MSBuild tests: 1) Test Failure : Xamarin.iOS.Tasks.TargetTests.RebuildExecutable_NoModifications #1: ../MySingleView/bin/iPhoneSimulator/Debug/MySingleView.app/MySingleView Expected: 2017-11-30 10:04:20.000 But was: 2017-11-30 10:04:22.000 Fixes xamarin/maccore#592.

The MSBuild tasks will codesign an executable if the executable's timestamp is later than `_CodeSignature/CodeResources`'s timestamp (or if `_CodeSignature/CodeResources` doesn't exist). Unfortunately, the codesign executable modifies both of those files, and the executable last. This means that even just after running codesign, the executable's timestamp might be later than `_CodeSignature/CodeResources`'s timestamp (due to HFS+'s one-second timestamp resolution, this might happen all within the same second, which means that this is a random issue: the problem only occurs if the executable was modified at least a second later than `_CodeSignature/CodeResources`.) So make sure to touch `_CodeSignature/CodeResources` after running codesign, so that the next time a build occurs (with no modifications), we don't resign needlessly. Fixes this (random) test failure when running the MSBuild tests: 1) Test Failure : Xamarin.iOS.Tasks.TargetTests.RebuildExecutable_NoModifications #1: ../MySingleView/bin/iPhoneSimulator/Debug/MySingleView.app/MySingleView Expected: 2017-11-30 10:04:20.000 But was: 2017-11-30 10:04:22.000 Fixes https://github.com/xamarin/maccore/issues/592.

…tnet#4231) The MSBuild tasks will codesign an executable if the executable's timestamp is later than `_CodeSignature/CodeResources`'s timestamp (or if `_CodeSignature/CodeResources` doesn't exist). Unfortunately, the codesign executable modifies both of those files, and the executable last. This means that even just after running codesign, the executable's timestamp might be later than `_CodeSignature/CodeResources`'s timestamp (due to HFS+'s one-second timestamp resolution, this might happen all within the same second, which means that this is a random issue: the problem only occurs if the executable was modified at least a second later than `_CodeSignature/CodeResources`.) So make sure to touch `_CodeSignature/CodeResources` after running codesign, so that the next time a build occurs (with no modifications), we don't resign needlessly. Fixes this (random) test failure when running the MSBuild tests: 1) Test Failure : Xamarin.iOS.Tasks.TargetTests.RebuildExecutable_NoModifications #1: ../MySingleView/bin/iPhoneSimulator/Debug/MySingleView.app/MySingleView Expected: 2017-11-30 10:04:20.000 But was: 2017-11-30 10:04:22.000 Fixes https://github.com/xamarin/maccore/issues/592.

@akoeplinger

dotnet#6011) * [msbuild] Add reference to `System.Drawing.Common.dll` to XI projects. Fixes mono/mono#13483 : ``` @akoeplinger: Since we moved types from Mono.Android.dll and Xamarin.iOS/WatchOS/TVOS.dll to System.Drawing.Common.dll user projects would fail to compile. We need to add some msbuild logic to add a reference to the assembly automatically. ``` * [msbuild] Implement the same fix for XM projects as well. * [msbuild] Update Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_* tests. We're including a new assembly, which means the Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_* must be updated accordingly. Also modify these tests so that test assert that fails lists the actual assembly that's missing, i.e. instead of this: 1) Test Failure : Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_Executable #1 Expected: 6 But was: 7 we now print: 1) Test Failure : Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_Executable References Expected: equivalent to < "mscorlib.dll", "MyLibrary.dll", "System.Core.dll", "System.dll", "System.Xml.dll", "Xamarin.iOS.dll" > But was: < "mscorlib.dll", "MyLibrary.dll", "System.Core.dll", "System.dll", "System.Drawing.Common.dll", "System.Xml.dll", "Xamarin.iOS.dll" > * [tests] Adjust Xamarin.MMP.Tests.AssemblyReferencesTests.ShouldNotAllowReference_ToSystemDrawing. The test was verifying that referencing System.Drawing.dll and trying to use System.Drawing.RectangleF would fail to compile (because System.Drawing.dll shouldn't be resolved in this case). The addition of System.Drawing.Common.dll breaks this assumption, because now we ship System.Drawing.RectangleF, so the code that was supposed to fail to compile works just fine instead. So modify the test to verify that there's no System.Drawing.dll in the final bundle. * Remove workarounds for mono/mono#13483. * [msbuild] Create a way out if automatically referencing System.Drawing.Common.dll causes problems. * [msbuild] Adjust variable name and boolean logic according to review.

@akoeplinger

…projects. (dotnet#6035) * [msbuild] Add reference to `System.Drawing.Common.dll` to XI projects. Fixes mono/mono#13483 : ``` @akoeplinger: Since we moved types from Mono.Android.dll and Xamarin.iOS/WatchOS/TVOS.dll to System.Drawing.Common.dll user projects would fail to compile. We need to add some msbuild logic to add a reference to the assembly automatically. ``` * [msbuild] Implement the same fix for XM projects as well. * [msbuild] Update Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_* tests. We're including a new assembly, which means the Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_* must be updated accordingly. Also modify these tests so that test assert that fails lists the actual assembly that's missing, i.e. instead of this: 1) Test Failure : Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_Executable #1 Expected: 6 But was: 7 we now print: 1) Test Failure : Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_Executable References Expected: equivalent to < "mscorlib.dll", "MyLibrary.dll", "System.Core.dll", "System.dll", "System.Xml.dll", "Xamarin.iOS.dll" > But was: < "mscorlib.dll", "MyLibrary.dll", "System.Core.dll", "System.dll", "System.Drawing.Common.dll", "System.Xml.dll", "Xamarin.iOS.dll" > * [tests] Adjust Xamarin.MMP.Tests.AssemblyReferencesTests.ShouldNotAllowReference_ToSystemDrawing. The test was verifying that referencing System.Drawing.dll and trying to use System.Drawing.RectangleF would fail to compile (because System.Drawing.dll shouldn't be resolved in this case). The addition of System.Drawing.Common.dll breaks this assumption, because now we ship System.Drawing.RectangleF, so the code that was supposed to fail to compile works just fine instead. So modify the test to verify that there's no System.Drawing.dll in the final bundle. * Remove workarounds for mono/mono#13483. * [msbuild] Create a way out if automatically referencing System.Drawing.Common.dll causes problems. * [msbuild] Adjust variable name and boolean logic according to review.

…6821) We were getting: ``` Xamarin.MTouch.LinkerWarnings: The warning 'MT5203: Native linking warning: warning: ignoring file /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/test-libraries/.libs/ios/libtest.x86_64.a, building for iOS Simulator-i386 but attempting to link with file built for unknown-archive' was not found in the output: Message #1 did not match: actual: 'Native linking warning: warning: ignoring file /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/test-libraries/.libs/ios/libtest.x86_64.a, building for iOS Simulator-i386 but attempting to link with file built for iOS Simulator-x86_64' expected: 'Native linking warning: warning: ignoring file /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/test-libraries/.libs/ios/libtest.x86_64.a, building for iOS Simulator-i386 but attempting to link with file built for unknown-archive' ```

dotnet#7075) I get this otherwise on the watch4 in debug mode (with interp): ``` Process 1255 stopped * thread #1, name = 'tid_303', queue = 'com.apple.main-thread', stop reason = EXC_RESOURCE RESOURCE_TYPE_MEMORY (limit=80 MB, unused=0x0) frame #0: 0x1e185ae8 CoreGraphics`x_malloc + 44 CoreGraphics`x_malloc: -> 0x1e185ae8 <+44>: str w19, [x0], #0x10 0x1e185aec <+48>: ldp x29, x30, [sp, #0x10] 0x1e185af0 <+52>: ldp x20, x19, [sp], #0x20 0x1e185af4 <+56>: ret Target 0: (monotouchtest) stopped. ```

…s in .NET (dotnet#9464) A System.Drawing.Point test fails because it tests GetHashCode, which returns a different value in .NET. None of the System.Drawing tests actually test any of our code (when using .NET), so the fix is to just not include the System.Drawing tests in the first place. Fixes this test failure: MonoTests.System.Drawing.PointTest [FAIL] GetHashCodeTest : #1 Expected: 32 But was: 1527927283 at MonoTests.System.Drawing.PointTest.GetHashCodeTest() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/builds/mono-ios-sdk-destdir/ios-sources/mcs/class/System.Drawing/Test/System.Drawing/TestPoint.cs:line 198

…r the message changed. (dotnet#9485) This regressed here: d7ab847 Fixes this failure: Xamarin.MTouch.MT0113_linker: The error 'MT0113: Native code sharing has been disabled for the extension 'testServiceExtension' because the managed linker settings are different between the container app (None) and the extension (All).' was not found in the output: Message #1 did not match: actual: 'Native code sharing has been disabled for the extension 'testServiceExtension' because the managed linker settings are different between the container app (None) and the extension (Full).' expected: 'Native code sharing has been disabled for the extension 'testServiceExtension' because the managed linker settings are different between the container app (None) and the extension (All).'

…line. Fixes this startup crash in link all: 2020-08-26 19:56:03.936330+0200 link all[45665:6121665] Could not register the assembly 'link all': ObjCRuntime.RuntimeException: The registrar can't convert from 'LinkAll.Attributes.SmartEnum' to 'Foundation.NSString' for the parameter 'value' in the method LinkAll.Attributes.SmartConsumer.SetSmartEnumValue. at Registrar.Registrar.ObjCMethod.get_NativeParameters() at Registrar.Registrar.ComputeSignature(Type DeclaringType, MethodBase Method, ObjCMember member, Boolean isCategoryInstance, Boolean isBlockSignature) at Registrar.Registrar.ObjCMethod.ComputeSignature() at Registrar.Registrar.ObjCMethod.get_Signature() at Registrar.Registrar.ObjCMethod.get_Trampoline() at Registrar.DynamicRegistrar.RegisterMethod(ObjCMethod method) at Registrar.DynamicRegistrar.OnRegisterType(ObjCType type) at Registrar.Registrar.RegisterTypeUnsafe(Type type, List`1& exceptions) at Registrar.Registrar.RegisterAssembly(Assembly assembly) 2020-08-26 19:56:03.939327+0200 link all[45665:6121665] System.AggregateException: One or more errors occurred. (The registrar can't convert from 'LinkAll.Attributes.SmartEnum' to 'Foundation.NSString' for the return value in the method LinkAll.Attributes.SmartConsumer.GetSmartEnumValue.) (The registrar can't convert from 'LinkAll.Attributes.SmartEnum' to 'Foundation.NSString' for the return value in the method LinkAll.Attributes.SmartConsumer.GetSmartEnumValue.) (The registrar can't convert from 'LinkAll.Attributes.SmartEnum' to 'Foundation.NSString' for the parameter 'value' in the method LinkAll.Attributes.SmartConsumer.SetSmartEnumValue.) ---> ObjCRuntime.RuntimeException: The registrar can't convert from 'LinkAll.Attributes.SmartEnum' to 'Foundation.NSString' for the return value in the method LinkAll.Attributes.SmartConsumer.GetSmartEnumValue. at Registrar.Registrar.ObjCMethod.get_NativeReturnType() at Registrar.Registrar.ComputeSignature(Type DeclaringType, MethodBase Method, ObjCMember member, Boolean isCategoryInstance, Boolean isBlockSignature) at Registrar.Registrar.ObjCMethod.ComputeSignature() at Registrar.Registrar.ObjCMethod.ValidateSignature(List`1& exceptions) --- End of inner exception stack trace --- ---> (Inner Exception #1) ObjCRuntime.RuntimeException: The registrar can't convert from 'LinkAll.Attributes.SmartEnum' to 'Foundation.NSString' for the return value in the method LinkAll.Attributes.SmartConsumer.GetSmartEnumValue. at Registrar.Registrar.ObjCMethod.get_NativeReturnType() at Registrar.Registrar.VerifyInSdk(List`1& exceptions, ObjCMethod method) at Registrar.Registrar.ObjCType.Add(ObjCMethod method, List`1& exceptions) at Registrar.Registrar.RegisterTypeUnsafe(Type type, List`1& exceptions)<--- ---> (Inner Exception #2) ObjCRuntime.RuntimeException: The registrar can't convert from 'LinkAll.Attributes.SmartEnum' to 'Foundation.NSString' for the parameter 'value' in the method LinkAll.Attributes.SmartConsumer.SetSmartEnumValue. at Registrar.Registrar.ObjCMethod.get_NativeParameters() at Registrar.Registrar.ComputeSignature(Type DeclaringType, MethodBase Method, ObjCMember member, Boolean isCategoryInstance, Boolean isBlockSignature) at Registrar.Registrar.ObjCMethod.ComputeSignature() at Registrar.Registrar.ObjCMethod.ValidateSignature(List`1& exceptions)<--- ================================================================= Native Crash Reporting ================================================================= Got a abrt while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= ================================================================= Native stacktrace: ================================================================= 0x10d57eb0e - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libmonosgen-2.0.dylib : mono_dump_native_crash_info 0x10d52b437 - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libmonosgen-2.0.dylib : mono_handle_native_crash 0x10d57e365 - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libmonosgen-2.0.dylib : sigabrt_signal_handler 0x7fff51c005fd - /Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 13.5.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libsystem_platform.dylib : _sigtramp 0x0 - Unknown 0x7fff51af0b7c - /Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 13.5.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libsystem_c.dylib : abort 0x10d32478f - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libxamarin-debug.dylib : xamarin_unhandled_exception_handler 0x10d5eef68 - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libmonosgen-2.0.dylib : mono_invoke_unhandled_exception_hook 0x10d52ade0 - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libmonosgen-2.0.dylib : mono_handle_exception_internal 0x10d5296c1 - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libmonosgen-2.0.dylib : mono_handle_exception 0x10d579582 - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libmonosgen-2.0.dylib : mono_amd64_throw_exception 0x10d91b5b0 - Unknown 0x10d3244eb - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libxamarin-debug.dylib : xamarin_process_managed_exception 0x10d324367 - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libxamarin-debug.dylib : xamarin_process_managed_exception_gchandle 0x10d336851 - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libxamarin-debug.dylib : xamarin_main 0x10d217ced - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/link all : main 0x7fff51a231fd - /Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 13.5.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libdyld.dylib : start

…line. (dotnet#9537) This also means: * Adding the ExceptionalSubStep step to the build. * Adding a few workarounds for missing/different linker API. This fixes this startup crash in link all: 2020-08-26 19:56:03.936330+0200 link all[45665:6121665] Could not register the assembly 'link all': ObjCRuntime.RuntimeException: The registrar can't convert from 'LinkAll.Attributes.SmartEnum' to 'Foundation.NSString' for the parameter 'value' in the method LinkAll.Attributes.SmartConsumer.SetSmartEnumValue. at Registrar.Registrar.ObjCMethod.get_NativeParameters() at Registrar.Registrar.ComputeSignature(Type DeclaringType, MethodBase Method, ObjCMember member, Boolean isCategoryInstance, Boolean isBlockSignature) at Registrar.Registrar.ObjCMethod.ComputeSignature() at Registrar.Registrar.ObjCMethod.get_Signature() at Registrar.Registrar.ObjCMethod.get_Trampoline() at Registrar.DynamicRegistrar.RegisterMethod(ObjCMethod method) at Registrar.DynamicRegistrar.OnRegisterType(ObjCType type) at Registrar.Registrar.RegisterTypeUnsafe(Type type, List`1& exceptions) at Registrar.Registrar.RegisterAssembly(Assembly assembly) 2020-08-26 19:56:03.939327+0200 link all[45665:6121665] System.AggregateException: One or more errors occurred. (The registrar can't convert from 'LinkAll.Attributes.SmartEnum' to 'Foundation.NSString' for the return value in the method LinkAll.Attributes.SmartConsumer.GetSmartEnumValue.) (The registrar can't convert from 'LinkAll.Attributes.SmartEnum' to 'Foundation.NSString' for the return value in the method LinkAll.Attributes.SmartConsumer.GetSmartEnumValue.) (The registrar can't convert from 'LinkAll.Attributes.SmartEnum' to 'Foundation.NSString' for the parameter 'value' in the method LinkAll.Attributes.SmartConsumer.SetSmartEnumValue.) ---> ObjCRuntime.RuntimeException: The registrar can't convert from 'LinkAll.Attributes.SmartEnum' to 'Foundation.NSString' for the return value in the method LinkAll.Attributes.SmartConsumer.GetSmartEnumValue. at Registrar.Registrar.ObjCMethod.get_NativeReturnType() at Registrar.Registrar.ComputeSignature(Type DeclaringType, MethodBase Method, ObjCMember member, Boolean isCategoryInstance, Boolean isBlockSignature) at Registrar.Registrar.ObjCMethod.ComputeSignature() at Registrar.Registrar.ObjCMethod.ValidateSignature(List`1& exceptions) --- End of inner exception stack trace --- ---> (Inner Exception #1) ObjCRuntime.RuntimeException: The registrar can't convert from 'LinkAll.Attributes.SmartEnum' to 'Foundation.NSString' for the return value in the method LinkAll.Attributes.SmartConsumer.GetSmartEnumValue. at Registrar.Registrar.ObjCMethod.get_NativeReturnType() at Registrar.Registrar.VerifyInSdk(List`1& exceptions, ObjCMethod method) at Registrar.Registrar.ObjCType.Add(ObjCMethod method, List`1& exceptions) at Registrar.Registrar.RegisterTypeUnsafe(Type type, List`1& exceptions)<--- ---> (Inner Exception #2) ObjCRuntime.RuntimeException: The registrar can't convert from 'LinkAll.Attributes.SmartEnum' to 'Foundation.NSString' for the parameter 'value' in the method LinkAll.Attributes.SmartConsumer.SetSmartEnumValue. at Registrar.Registrar.ObjCMethod.get_NativeParameters() at Registrar.Registrar.ComputeSignature(Type DeclaringType, MethodBase Method, ObjCMember member, Boolean isCategoryInstance, Boolean isBlockSignature) at Registrar.Registrar.ObjCMethod.ComputeSignature() at Registrar.Registrar.ObjCMethod.ValidateSignature(List`1& exceptions)<--- ================================================================= Native Crash Reporting ================================================================= Got a abrt while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= ================================================================= Native stacktrace: ================================================================= 0x10d57eb0e - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libmonosgen-2.0.dylib : mono_dump_native_crash_info 0x10d52b437 - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libmonosgen-2.0.dylib : mono_handle_native_crash 0x10d57e365 - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libmonosgen-2.0.dylib : sigabrt_signal_handler 0x7fff51c005fd - /Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 13.5.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libsystem_platform.dylib : _sigtramp 0x0 - Unknown 0x7fff51af0b7c - /Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 13.5.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libsystem_c.dylib : abort 0x10d32478f - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libxamarin-debug.dylib : xamarin_unhandled_exception_handler 0x10d5eef68 - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libmonosgen-2.0.dylib : mono_invoke_unhandled_exception_hook 0x10d52ade0 - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libmonosgen-2.0.dylib : mono_handle_exception_internal 0x10d5296c1 - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libmonosgen-2.0.dylib : mono_handle_exception 0x10d579582 - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libmonosgen-2.0.dylib : mono_amd64_throw_exception 0x10d91b5b0 - Unknown 0x10d3244eb - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libxamarin-debug.dylib : xamarin_process_managed_exception 0x10d324367 - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libxamarin-debug.dylib : xamarin_process_managed_exception_gchandle 0x10d336851 - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/libxamarin-debug.dylib : xamarin_main 0x10d217ced - /Users/rolf/Library/Developer/CoreSimulator/Devices/289E372A-501C-4499-A1A6-59C5B3B6A9AE/data/Containers/Bundle/Application/5CB344E3-EC61-4720-92E6-4C8B91A67A85/link all.app/link all : main 0x7fff51a231fd - /Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 13.5.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libdyld.dylib : start

**Example #1.** Signing a framework binary is the **same** thing as signing the framework directory. ``` $ codesign -v --force --timestamp=none --sign - bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework/lame bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework/lame: replacing existing signature bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework/lame: signed bundle with Mach-O thin (arm64) [io.sourceforge.lame] $ codesign -v --force --timestamp=none --sign - bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework: replacing existing signature bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework: signed bundle with Mach-O thin (arm64) [io.sourceforge.lame] ``` Nice right ? Pretty much until... **Example #2.** Signing a framework binary is **NOT** the **same** thing as signing the framework directory. ``` $ codesign -v --force --timestamp=none --sign - bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework/flac bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework/flac: replacing existing signature bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework/flac: signed Mach-O thin (arm64) [flac-55554944583d2f02282c33d8bfed082daa857e30] $ codesign -v --force --timestamp=none --sign - bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework: replacing existing signature bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework: signed bundle with Mach-O thin (arm64) [org.xiph.flac] ``` In this case signing the binary `flac` does not produce the `_CodeSignature` directory and fails our msbuild Codesign task The fix is to detect if we're signing a framework like `A.framework/A` and change this to sign `A.framework` as this will always work.

…otnet#10309) **Example #1.** Signing a framework binary is the **same** thing as signing the framework directory. ``` $ codesign -v --force --timestamp=none --sign - bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework/lame bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework/lame: replacing existing signature bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework/lame: signed bundle with Mach-O thin (arm64) [io.sourceforge.lame] $ codesign -v --force --timestamp=none --sign - bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework: replacing existing signature bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework: signed bundle with Mach-O thin (arm64) [io.sourceforge.lame] ``` Nice right ? Pretty much until... **Example #2.** Signing a framework binary is **NOT** the **same** thing as signing the framework directory. ``` $ codesign -v --force --timestamp=none --sign - bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework/flac bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework/flac: replacing existing signature bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework/flac: signed Mach-O thin (arm64) [flac-55554944583d2f02282c33d8bfed082daa857e30] $ codesign -v --force --timestamp=none --sign - bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework: replacing existing signature bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework: signed bundle with Mach-O thin (arm64) [org.xiph.flac] ``` In this case signing the binary `flac` does not produce the `_CodeSignature` directory and fails our msbuild Codesign task The fix is to detect if we're signing a framework like `A.framework/A` and change this to sign `A.framework` as this will always work.

Not sure why it was added to `DisposableObject` but it seems the compiler is not happy to use the extension method for the `NativeObject` subclass even if it implement `INativeObject` (that might be the reason why?) So remove it from `NativeObjectExtensions` for .net - as I guess it's too late to remove from the recent `DisposableObject` in legacy. The platform assemblies only use it for `NativeObject` subclass so it's not an big issue... as I assume there's not many `INativeObject` user code that does not use (or should be using) `NativeObject`. Fix #1: avoid using `IntPtr` when `NativeHandle` is defined since the compiler will add (not really needed) implicit conversions everywhere. Fix #2: ensure the spirit/contract of `GetCheckedHandle` always work. IOW the goal of `GetCheckedHandle` is to ensure you never get a `nil` handle, since some native API will crash if they given `nil` However it's still currently possible, with multithreaded code, to get a `Zero` value from `GetCheckedHandle`. From a quick look at the C# code it seems fine. It's easier to see the problem looking at the IL. ```il .method public hidebysig instance valuetype ObjCRuntime.NativeHandle GetCheckedHandle () cil managed { // Method begins at RVA 0x6c8c // Header size: 1 // Code size: 31 (0x1f) .maxstack 8 IL_0000: ldarg.0 IL_0001: ldfld valuetype ObjCRuntime.NativeHandle ObjCRuntime.DisposableObject::handle IL_0006: ldsfld valuetype ObjCRuntime.NativeHandle ObjCRuntime.NativeHandle::Zero IL_000b: call bool ObjCRuntime.NativeHandle::op_Equality(valuetype ObjCRuntime.NativeHandle, valuetype ObjCRuntime.NativeHandle) IL_0010: brfalse.s IL_0018 IL_0012: ldarg.0 IL_0013: call void ObjCRuntime.ThrowHelper::ThrowObjectDisposedException(object) IL_0018: ldarg.0 IL_0019: ldfld valuetype ObjCRuntime.NativeHandle ObjCRuntime.DisposableObject::handle IL_001e: ret } // end of method DisposableObject::GetCheckedHandle ``` `IL_0001` loads the field and then `IL_006` compares it to `Zero`. If it's not `Zero` then `IL_0019` loads the field **again** before returning it `IL_0001e` to the caller. So if another thread sets the `handle` of this instance to `Zero` between the two `ldfld` instructions then the caller will get `Zero` and this can crash the application. Of course what will happen if you use the _old_ handle is _somewhat_ undefined and depends if the native object still exists. There's a **very** good chance it does it the managed object i running (so it has not been collected).

[xharness] Get new mlaunch for beta 4.

2c892e2

spouliot merged commit 6be6e66 into spouliot:beta4-bump Aug 2, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[xharness] Get new mlaunch for beta 4. #1

[xharness] Get new mlaunch for beta 4. #1

rolfbjarne commented Aug 2, 2016

[xharness] Get new mlaunch for beta 4. #1

[xharness] Get new mlaunch for beta 4. #1

Conversation

rolfbjarne commented Aug 2, 2016