[xibuild] Fix incorrect mscorlib.dll being used#6068
Merged
rolfbjarne merged 2 commits intodotnet:masterfrom May 17, 2019
Merged
[xibuild] Fix incorrect mscorlib.dll being used#6068rolfbjarne merged 2 commits intodotnet:masterfrom
rolfbjarne merged 2 commits intodotnet:masterfrom
Conversation
The `GuiUnit_NET_4_5` project, when built with `xibuild` uses the wrong `mscorlib.dll`. From dotnet#5760 (comment) : ``` - mscorlib.dll is being used from mono/4.5 and the other system assemblies are from mono/4.5-api - GuiNet* project is built with xibuild What is happening here is: xibuild sets[1] `SetToolsetProperty ("TargetFrameworkRootPath", FrameworksDirectory + Path.DirectorySeparatorChar);` which points to `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks`. This causes $(FrameworkPathOverride) to be set[2] to `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks/.NETFramework/v4.5`, but that doesn't have a mscorlib.dll, so it gets reset[3] to /Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5/. If we don't set TargetFrameworkRoothPath, then we get `FrameworkPathOverride = /Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5-api`, causing `_ExplicitReference=/Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5-api/mscorlib.dll`(correct one) to be used. ``` Fixes dotnet#5760 1. https://github.com/xamarin/xamarin-macios/blob/master/tools/xibuild/Main.cs#L209 2. https://github.com/mono/msbuild/blob/xplat-master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L79 3. https://github.com/mono/msbuild/blob/xplat-master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L84
This reverts commit 9bd927b. The previous commit for xibuild removes the need for this.
Member
Author
|
Let's see if this breaks anything! |
spouliot
approved these changes
May 16, 2019
Contributor
|
Build success |
rolfbjarne
approved these changes
May 17, 2019
rolfbjarne
pushed a commit
to rolfbjarne/macios
that referenced
this pull request
Jun 19, 2019
* [xibuild] Fix incorrect mscorlib.dll being used The `GuiUnit_NET_4_5` project, when built with `xibuild` uses the wrong `mscorlib.dll`. From dotnet#5760 (comment) : ``` - mscorlib.dll is being used from mono/4.5 and the other system assemblies are from mono/4.5-api - GuiNet* project is built with xibuild What is happening here is: xibuild sets[1] `SetToolsetProperty ("TargetFrameworkRootPath", FrameworksDirectory + Path.DirectorySeparatorChar);` which points to `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks`. This causes $(FrameworkPathOverride) to be set[2] to `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks/.NETFramework/v4.5`, but that doesn't have a mscorlib.dll, so it gets reset[3] to /Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5/. If we don't set TargetFrameworkRoothPath, then we get `FrameworkPathOverride = /Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5-api`, causing `_ExplicitReference=/Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5-api/mscorlib.dll`(correct one) to be used. ``` Fixes dotnet#5760 1. https://github.com/xamarin/xamarin-macios/blob/master/tools/xibuild/Main.cs#L209 2. https://github.com/mono/msbuild/blob/xplat-master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L79 3. https://github.com/mono/msbuild/blob/xplat-master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L84 * Revert "Workaround dotnet#5760 in generator csproj" This reverts commit 9bd927b. The previous commit for xibuild removes the need for this.
rolfbjarne
added a commit
that referenced
this pull request
Jun 19, 2019
* Bump VSMac to 8.1.0.2742 to fix msbuild issues (#6279) * Bump VSMac to 8.1.0.2742 to fix msbuild issues This is required to get the support for the msbuild `ToolsVersion` change from `15.0` to `Current`. * [tests][msbuild] Fix Binding resources test with updated msbuild Test failure with updated msbuild and vsmac 8.1: ``` Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").ShouldNotUnnecessarilyRebuildBindingProject(True) Binding project build did not create package? Expected: True But was: False at Xamarin.iOS.Tasks.NativeReferencesNoEmbedding.ShouldNotUnnecessarilyRebuildBindingProject (System.Boolean framework) [0x000a0] in <74b8f7d8a53e40109916d305bb4d7403>:0 at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&) at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo cul ture) [0x0006a] in <0519fa732e8845b6a809ce9180f541db>:0 ``` The test builds the project multiple times. Before the 3rd build, the project file's timestamp is updated and expects that the binding package will be rebuilt. But it is not, because the target `_CreateBindingResourcePackage` doesn't depend on that project file. So, add that to the target inputs. * [nuget] Use xibuild to run nuget Fix errors seen during `nuget restore` for tests: ``` Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xammac_tests/xammac_tests.csproj(213,3): error MSB4024: The imported project file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets" could not be loaded. Could not find file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets" ``` * [xibuild] Fix incorrect mscorlib.dll being used (#6068) * [xibuild] Fix incorrect mscorlib.dll being used The `GuiUnit_NET_4_5` project, when built with `xibuild` uses the wrong `mscorlib.dll`. From #5760 (comment) : ``` - mscorlib.dll is being used from mono/4.5 and the other system assemblies are from mono/4.5-api - GuiNet* project is built with xibuild What is happening here is: xibuild sets[1] `SetToolsetProperty ("TargetFrameworkRootPath", FrameworksDirectory + Path.DirectorySeparatorChar);` which points to `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks`. This causes $(FrameworkPathOverride) to be set[2] to `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks/.NETFramework/v4.5`, but that doesn't have a mscorlib.dll, so it gets reset[3] to /Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5/. If we don't set TargetFrameworkRoothPath, then we get `FrameworkPathOverride = /Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5-api`, causing `_ExplicitReference=/Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5-api/mscorlib.dll`(correct one) to be used. ``` Fixes #5760 1. https://github.com/xamarin/xamarin-macios/blob/master/tools/xibuild/Main.cs#L209 2. https://github.com/mono/msbuild/blob/xplat-master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L79 3. https://github.com/mono/msbuild/blob/xplat-master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L84 * Revert "Workaround #5760 in generator csproj" This reverts commit 9bd927b. The previous commit for xibuild removes the need for this. * [xibuild] Handle "incorrectly" cased msbuild property names (#6202) msbuild property names are case insensitive. While generating the custom app.config, in `SetToolsetProperty(..)` we try to update the property if it already exists. But the name lookup was case sensitive, thus causing the lookup to fail, resulting in two entries for the same property name differing only in case. Eg. `MSBuildSDKsPath` vs `MSBuildSdksPath`. Fixed to ignore case. Fixes mono/mono#14765 .
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #5760 .