-
Notifications
You must be signed in to change notification settings - Fork 528
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot build projects with latest mono 2018-04 #1845
Comments
@radical any updates here? This is blocking a lot of testing. |
nuget restore of a solution is failing with the same error and this blocks the building of iOS projects in solution. nuget restore "/Users/xamarinqa/agent/_work/r26/a/xamarin-forms-book-samples/Chapter14/AbsoluteDemo/AbsoluteDemo.sln" |
MSuild/mono on osx supports a fallback search path for Target frameworks: `/Library/Frameworks/Mono.framework/External/xbuild-frameworks` This was earlier implemented in mono/msbuild via the app.config, but then was changed to be specified via the property `$(TargetFrameworkFallbackSearchPaths)`. And passed to `GetReferenceAssemblyPaths` task via a new task parameter `TargetFrameworkFallbackSearchPaths`. This also means that if any user of `GetReferenceAssemblyPaths` does not use this new parameter, then on osx, msbuild won't be using any fallback search path. MSBuild sets a default value for that property (`$(TargetFrameworkFallbackSearchPaths)`) on osx, but XA's use of GRAP task needs to pass that property as an argument for the new parameter. Since, there is a change in behavior in msbuild, this brings up multiple cases: ``` XA mono/msbuild old/existing older (with old behavior) => No change required old/existing newer (new param+prop) => Change required in msbuild to not break this [1] newer older (with old behavior) => Use GRAP task w/o the new parameter newer newer (new param+prop) => Use GRAP task with the new parameter+property ``` The last two cases are what need changes in XA and this PR does that. 1. if we are running on a version that doesn't support the new param, then don't use it 2. if we are running on a version that does support the new param on GRAP task, then use that and pass the property `$(TargetFrameworkFallbackSearchPaths)` as an argument. The *version* (value of `$(MSBuildVersion)`) above also has two cases: 1. On mono, version older than the one for the commit that introduced the change 2. And on full framework/windows, anything newer than 15.8 preview 3, since preview4 will have the GRAP task change. Fixes dotnet#1845 . --- 1. To avoid breaking older versions of XA which don't use pass the new property to the task, msbuild internally uses the default path for osx if none was specified. This behavior can be disabled by setting `DISABLE_FALLBACK_PATHS_HACK_IN_GRAP_OSX`.
.. fallback paths. MSuild/mono on osx supports a fallback search path for Target frameworks: `/Library/Frameworks/Mono.framework/External/xbuild-frameworks` This was earlier implemented in mono/msbuild via the app.config, but then was changed to be specified via the property `$(TargetFrameworkFallbackSearchPaths)`. And passed to `GetReferenceAssemblyPaths` task via a new task parameter `TargetFrameworkFallbackSearchPaths`. This also means that if any user of `GetReferenceAssemblyPaths` does not use this new parameter, then on osx, msbuild won't be using any fallback search path. MSBuild sets a default value for that property (`$(TargetFrameworkFallbackSearchPaths)`) on osx, but XA's use of GRAP task needs to pass that property as an argument for the new parameter. Since, there is a change in behavior in msbuild, this brings up multiple cases: ``` XA mono/msbuild old/existing older (with old behavior) => No change required old/existing newer (new param+prop) => Change required in msbuild to not break this [1] newer older (with old behavior) => Use GRAP task w/o the new parameter newer newer (new param+prop) => Use GRAP task with the new parameter+property ``` The last two cases are what need changes in XA and this PR does that. 1. if we are running on a version that doesn't support the new param, then don't use it 2. if we are running on a version that does support the new param on GRAP task, then use that and pass the property `$(TargetFrameworkFallbackSearchPaths)` as an argument. The *version* (value of `$(MSBuildVersion)`) above also has two cases: 1. On mono, version older than the one for the commit that introduced the change 2. And on full framework/windows, anything newer than 15.8 preview 3, since preview4 will have the GRAP task change. Fixes dotnet#1845 . --- 1. To avoid breaking older versions of XA which don't use pass the new property to the task, msbuild internally uses the default path for osx if none was specified. This behavior can be disabled by setting `DISABLE_FALLBACK_PATHS_HACK_IN_GRAP_OSX`.
.. fallback paths. MSuild/mono on osx supports a fallback search path for Target frameworks: `/Library/Frameworks/Mono.framework/External/xbuild-frameworks` This was earlier implemented in mono/msbuild via the app.config, but then was changed to be specified via the property `$(TargetFrameworkFallbackSearchPaths)` [1]. And passed to `GetReferenceAssemblyPaths` task via a new task parameter `TargetFrameworkFallbackSearchPaths`. This also means that if any user of `GetReferenceAssemblyPaths` does not use this new parameter, then on osx, msbuild won't be using any fallback search path. MSBuild sets a default value for that property (`$(TargetFrameworkFallbackSearchPaths)`) on osx, but XA's use of GRAP task needs to pass that property as an argument for the new parameter. Since, there is a change in behavior in msbuild, this brings up multiple cases: ``` XA mono/msbuild old/existing older (with old behavior) => No change required old/existing newer (new param+prop) => Change required in msbuild to not break this [2] newer older (with old behavior) => Use GRAP task w/o the new parameter newer newer (new param+prop) => Use GRAP task with the new parameter+property ``` The last two cases are what need changes in XA and this PR does that. 1. if we are running on a version that doesn't support the new param, then don't use it 2. if we are running on a version that does support the new param on GRAP task, then use that and pass the property `$(TargetFrameworkFallbackSearchPaths)` as an argument. The *version* (value of `$(MSBuildVersion)`) above also has two cases: 1. On mono, version older than the one for the commit that introduced the change 2. And on full framework/windows, anything newer than 15.8 preview 3, since preview4 will have the GRAP task change. Fixes dotnet#1845 . --- 1. mono/msbuild@bdad9e6 2. To avoid breaking older versions of XA which don't use pass the new property to the task, msbuild internally uses the default path for osx if none was specified. This behavior can be disabled by setting `DISABLE_FALLBACK_PATHS_HACK_IN_GRAP_OSX`.
TargetFrameworks on osx have a default fallback search path: `/Library/Frameworks/Mono.framework/External/xbuild-frameworks` This was earlier implemented in mono/msbuild via the app.config, but then was changed to be specified via the property `$(TargetFrameworkFallbackSearchPaths)`. And passed to `GetReferenceAssemblyPaths` task via a new parameter `TargetFrameworkFallbackSearchPaths`. This also means that if any user of `GetReferenceAssemblyPaths` does not use this new parameter, then on osx, msbuild won't be using any fallback search path. In msbuild's targets files, we pass the new property as argument for the new GRAP task parameter. Accordingly, any non-msbuild users(targets) will need to update their use of GRAP task to get the search path. But this would break any existing/older users which are not using the new parameter and suddenly find that projects won't build because of the missing search path. Existing versions of Xamarin.Android are one example. To ensure that they can continue working, we internally use the fallback path if nothing is passed to the task. This can be disabled by setting `DISABLE_FALLBACK_PATHS_HACK_IN_GRAP_OSX` env var. Fixes dotnet/android#1845
TargetFrameworks on osx have a default fallback search path: `/Library/Frameworks/Mono.framework/External/xbuild-frameworks` This was earlier implemented in mono/msbuild via the app.config, but then was changed to be specified via the property `$(TargetFrameworkFallbackSearchPaths)`. And passed to `GetReferenceAssemblyPaths` task via a new parameter `TargetFrameworkFallbackSearchPaths`. This also means that if any user of `GetReferenceAssemblyPaths` does not use this new parameter, then on osx, msbuild won't be using any fallback search path. In msbuild's targets files, we pass the new property as argument for the new GRAP task parameter. Accordingly, any non-msbuild users(targets) will need to update their use of GRAP task to get the search path. But this would break any existing/older users which are not using the new parameter and suddenly find that projects won't build because of the missing search path. Existing versions of Xamarin.Android are one example. To ensure that they can continue working, we internally use the fallback path if nothing is passed to the task. This can be disabled by setting `DISABLE_FALLBACK_PATHS_HACK_IN_GRAP_OSX` env var. Fixes dotnet/android#1845
.. once, msbuild has an updated branch for 2018-06/master, then this will point to that. This also picks up fix for dotnet/android#1845 .
Pick up fix for dotnet/android#1845 .
.. once, msbuild has an updated branch for 2018-06/master, then this will point to that. This also picks up fix for dotnet/android#1845 .
Pick up fix for dotnet/android#1845 .
Fixes: #1130 Fixes: #1561 (comment) Fixes: #1845 Fixes: #1951 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=10087 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=11771 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=12850 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=18941 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=19436 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=25444 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=33208 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=58413 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59184 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59400 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59779 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60065 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60843 Context: mono/mono#6174 Context: mono/mono#6178 Context: mono/mono#6180 Context: mono/mono#6181 Context: mono/mono#6186 Context: mono/mono#6187 Context: mono/mono#6211 Context: mono/mono#6266 Context: mono/mono#6579 Context: mono/mono#6666 Context: mono/mono#6752 Context: mono/mono#6801 Context: mono/mono#6812 Context: mono/mono#6848 Context: mono/mono#6940 Context: mono/mono#6948 Context: mono/mono#6998 Context: mono/mono#6999 Context: mono/mono#7016 Context: mono/mono#7085 Context: mono/mono#7086 Context: mono/mono#7095 Context: mono/mono#7134 Context: mono/mono#7137 Context: mono/mono#7145 Context: mono/mono#7184 Context: mono/mono#7240 Context: mono/mono#7262 Context: mono/mono#7289 Context: mono/mono#7338 Context: mono/mono#7356 Context: mono/mono#7364 Context: mono/mono#7378 Context: mono/mono#7389 Context: mono/mono#7449 Context: mono/mono#7460 Context: mono/mono#7535 Context: mono/mono#7536 Context: mono/mono#7537 Context: mono/mono#7565 Context: mono/mono#7588 Context: mono/mono#7596 Context: mono/mono#7610 Context: mono/mono#7613 Context: mono/mono#7620 Context: mono/mono#7624 Context: mono/mono#7637 Context: mono/mono#7655 Context: mono/mono#7657 Context: mono/mono#7661 Context: mono/mono#7685 Context: mono/mono#7696 Context: mono/mono#7729 Context: mono/mono#7786 Context: mono/mono#7792 Context: mono/mono#7805 Context: mono/mono#7822 Context: mono/mono#7828 Context: mono/mono#7860 Context: mono/mono#7864 Context: mono/mono#7903 Context: mono/mono#7920 Context: mono/mono#8089 Context: mono/mono#8143 Context: mono/mono#8267 Context: mono/mono#8311 Context: mono/mono#8340 Context: mono/mono#8409 Context: mono/mono#8417 Context: mono/mono#8430 Context: mono/mono#8698 Context: mono/mono#8701 Context: mono/mono#8712 Context: mono/mono#8721 Context: mono/mono#8726 Context: mono/mono#8866 Context: mono/mono#9023 Context: mono/mono#9031 Context: mono/mono#9033 Context: mono/mono#9044 Context: mono/mono#9179 Context: mono/mono#9318 Context: mono/mono#9318 Context: xamarin/maccore#628 Context: xamarin/maccore#629 Context: xamarin/maccore#673
TargetFrameworks on osx have a default fallback search path: `/Library/Frameworks/Mono.framework/External/xbuild-frameworks` This was earlier implemented in mono/msbuild via the app.config, but then was changed to be specified via the property `$(TargetFrameworkFallbackSearchPaths)`. And passed to `GetReferenceAssemblyPaths` task via a new parameter `TargetFrameworkFallbackSearchPaths`. This also means that if any user of `GetReferenceAssemblyPaths` does not use this new parameter, then on osx, msbuild won't be using any fallback search path. In msbuild's targets files, we pass the new property as argument for the new GRAP task parameter. Accordingly, any non-msbuild users(targets) will need to update their use of GRAP task to get the search path. But this would break any existing/older users which are not using the new parameter and suddenly find that projects won't build because of the missing search path. Existing versions of Xamarin.Android are one example. To ensure that they can continue working, we internally use the fallback path if nothing is passed to the task. This can be disabled by setting `DISABLE_FALLBACK_PATHS_HACK_IN_GRAP_OSX` env var. Fixes dotnet/android#1845 (cherry picked from commit 8af44c5)
TargetFrameworks on osx have a default fallback search path: `/Library/Frameworks/Mono.framework/External/xbuild-frameworks` This was earlier implemented in mono/msbuild via the app.config, but then was changed to be specified via the property `$(TargetFrameworkFallbackSearchPaths)`. And passed to `GetReferenceAssemblyPaths` task via a new parameter `TargetFrameworkFallbackSearchPaths`. This also means that if any user of `GetReferenceAssemblyPaths` does not use this new parameter, then on osx, msbuild won't be using any fallback search path. In msbuild's targets files, we pass the new property as argument for the new GRAP task parameter. Accordingly, any non-msbuild users(targets) will need to update their use of GRAP task to get the search path. But this would break any existing/older users which are not using the new parameter and suddenly find that projects won't build because of the missing search path. Existing versions of Xamarin.Android are one example. To ensure that they can continue working, we internally use the fallback path if nothing is passed to the task. This can be disabled by setting `DISABLE_FALLBACK_PATHS_HACK_IN_GRAP_OSX` env var. Fixes dotnet/android#1845 (cherry picked from commit 8af44c5)
Bumps to mono/llvm:release_60@117a508c Bumps to xamarin/xamarin-android-api-compatibility:master@7ccb4802 $ git diff --shortstat e1af6ea..ab3c897d # mono 1443 files changed, 66049 insertions(+), 45745 deletions(-) $ git diff --shortstat bdb3a116..117a508c # llvm 26794 files changed, 4110589 insertions(+), 754376 deletions(-) $ git diff --shortstat c550d1bd..7ccb4802 # xamarin-android-api-compatibility 2 files changed, 16260 insertions(+), 12347 deletions(-) Incomplete summary of easily `grep`able fixes: Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=11199 Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=19436 Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=23668 Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=26983 Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=33728 Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=46917 fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=60065 Fixes: mono/mono#6173 Fixes: mono/mono#6466 Fixes: mono/mono#6647 Fixes: mono/mono#6834 Fixes: mono/mono#7058 Fixes: mono/mono#7137 Fixes: mono/mono#7260 Fixes: mono/mono#7305 Fixes: mono/mono#7402 Fixes: mono/mono#7525 Fixes: mono/mono#7610 Fixes: mono/mono#7649 Fixes: mono/mono#7655 Fixes: mono/mono#7683 Fixes: mono/mono#7685 Fixes: mono/mono#7716 Fixes: mono/mono#7731 Fixes: mono/mono#7785 Fixes: mono/mono#7828 Fixes: mono/mono#7944 Fixes: mono/mono#7947 Fixes: mono/mono#8036 Fixes: mono/mono#8074 Fixes: mono/mono#8089 Fixes: mono/mono#8112 Fixes: mono/mono#8122 Fixes: mono/mono#8143 Fixes: mono/mono#8149 Fixes: mono/mono#8152 Fixes: mono/mono#8175 Fixes: mono/mono#8177 Fixes: mono/mono#8250 Fixes: mono/mono#8267 Fixes: mono/mono#8273 Fixes: mono/mono#8282 Fixes: mono/mono#8310 Fixes: mono/mono#8311 Fixes: mono/mono#8329 Fixes: mono/mono#8340 Fixes: mono/mono#8372 Fixes: mono/mono#8407 Fixes: mono/mono#8409 Fixes: mono/mono#8422 Fixes: mono/mono#8430 Fixes: mono/mono#8439 fixes: mono/mono#8447 Fixes: mono/mono#8469 Fixes: mono/mono#8504 Fixes: mono/mono#8575 Fixes: mono/mono#8597 Fixes: mono/mono#8623 Fixes: mono/mono#8627 Fixes: mono/mono#8698 Fixes: mono/mono#8701 Fixes: mono/mono#8712 Fixes: mono/mono#8721 Fixes: mono/mono#8726 Fixes: mono/mono#8759 Fixes: mono/mono#8787 Fixes: mono/mono#8820 Fixes: mono/mono#8848 Fixes: mono/mono#8866 Fixes: mono/mono#8897 Fixes: mono/mono#8915 Fixes: mono/mono#8970 Fixes: mono/mono#8979 Fixes: mono/mono#9023 Fixes: mono/mono#9031 Fixes: mono/mono#9033 Fixes: mono/mono#9179 Fixes: mono/mono#9234 Fixes: mono/mono#9262 Fixes: mono/mono#9277 Fixes: mono/mono#9318 Fixes: mono/mono#9542 Fixes: mono/mono#9753 Fixes: mono/mono#9839 Fixes: mono/mono#9869 Fixes: mono/mono#9870 Fixes: mono/mono#9943 Fixes: mono/mono#9996 Fixes: mono/mono#10000 Fixes: mono/mono#10303 Fixes: mono/mono#10447 Fixes: mono/mono#10483 Fixes: mono/mono#10488 Fixes: xamarin/maccore#628 Fixes: xamarin/maccore#673 Fixes: #1561 (comment) Fixes: #1845 Fixes: xamarin/xamarin-macios#4347 Fixes: xamarin/xamarin-macios#4617 Fixes: xamarin/xamarin-macios#4618
Either a normal build or invoking
msbuild /restore
will error-out with the following:This issue is reproducible with build from mono/mono@07c8f25 but not with earlier build mono/mono@33a9dca which could suggest mono/mono@543b687 is the culprit
The text was updated successfully, but these errors were encountered: