Closed 7sharp9 closed 8 years ago
The error is here:
InvalidCastException,
ITask: Microsoft.Build.Framework.ITask, Microsoft.Build.Framework, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Task type: Xamarin.Android.Tasks.ResolveSdks, Xamarin.Android.Build.Tasks, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
Again this looks related to MSBuild SDK dependencies. It's possible a binding redirect for Microsoft.Build.Framework is needed from either 4.0.0.0 --> 12.0.0.0 (if Xamarin.Android.Build.Tasks implements the 4.0.0.0 interface) or 12.0.0.0 --> 14.0.0.0 (If Xamarin.Android.Build.Tasks implements the 14.0.0.0 interface). I expect the former. I would have thought Mono enabled those binding redirect by default though
Im not sure what is being suggested? A binding redirect for Xamarin.Android.Build.Tasks
I don't think that will be possible, it would involve QA'ing the whole Android build process.
It seems crazy we have to go to these lengths just to get the correct list of references and compiler options for type checking to work :-/
@dsyme what I don't understand is how xbuild and MSBuild.exe (the commandline tools themselves) react to the ToolsVersion tag in the project file to load the appropriate MSBuild assembly so that the cast of custom tasks succeeds in general.
I can see that the mono team are having trouble with similar issues as well https://github.com/mono/mono/commit/80093e6a4ded9e23afaa29c9181cda3a7fe35c5b
@7sharp9 can you pull in whoever knows about Xamarin.Android.Build.Tasks
? @dsyme on what assembly do you think we should add the binding redirect?
I cant expect a redirect to be added to Xamarin.Android.Build.Tasks
It looks to be built with normal msbuild dll references that are used for 4.0.
Yeah, I understand that, that's why I'm wondering how xbuild handles it so we can emulate that. Maybe @atsushieno could help. If Xamarin.Android.Build.Tasks
it uses the 4.0 references, and after that commit (https://github.com/mono/mono/commit/80093e6a4ded9e23afaa29c9181cda3a7fe35c5b) xbuild uses 12.0, then I wonder if xbuild will have the same problem.
Any further insights @dsyme @rneatherway or do I think about going back to the old project options method
It looks like the output above which contains the cast exception is from FCS itself, invoking the MSBuild API. I presume this is FCS hosted inside XamarinStudio.exe?
Have you checked that the Microsoft.Build redirects (* --> 14.0.0.0) are active for XamarinStudio.exe? Could it be that you need to add those redirects ?
If you can't add them then you may need to run that specific FCS call out-of-process (or in an app domain) in a way that has the appropriate redirects active.
BTW it would probably be reasonable to include an FSharp.Compiler.Service.dll.config which contains all the binding redirects FCS may need when activated as a component, e.g. in an app domain of its own. Or to at least document those redirects in a page like the FSharp.Core one.
Yes adding the redirect to the monodevelop config makes the android issue resolve, Ive asked about adding them in. Before this release I don't think msbuild was using inside of monodevelop, but now its been used as part of the project system to allow resolution of $(blah)
properties etc.
This is good news. I wonder if this would solve @tpetricek's problem where VS2015 was installed. I suppose I should add this to fsac as well.
Hello, hello. My change is to bring consistency in xbuild.exe itself and has nothing to do with the MSBuild assemblies that are used in each build. For example, when we build a project that targets .NET 4.5, we load "4.0" version of Microsoft.Build.*.dll for builds. The same should apply to Xamarin.Android.
I'm not very familiar with those irregularly versioned MSBuild assemblies and likely missing some points, but I have doubts on the solutions you guys are trying. Should ANY MSBuild task implementors (like Xamarin.Android.Build.Tasks) add assembly redirects for their MSBuild based libraries, so that APPS (like FSharp.Compiler.Service) that reference Microsoft.Build.*.dll don't break like this? Isn't it that by adding references to "non-framework" MSBuild assemblies (xbuild_12/xbuild_14 in mono, no idea where they reside on Windows) you are rather bringing incompatibility with framework-based MSBuild task implementators? Is there any particular reason you dare to reference those v12 assemblies in FSharp.Compiler.Service.fsproj? My guess is that if it just references "4.0" assemblies then this doesn't happen.
I see. I am the one that changed to reference the v12 assemblies, because fsproj files with ToolsVersion
set to 12 were not correctly understood by the Mono Microsoft.Build.*.dll otherwise. Perhaps this was a bug that is now fixed?
Probably? The problem I resolved was that when our xbuild script runs, it points to xbuild_12 and thus supposed to load Microsoft.Build.Tasks.dll (as well as other Microsoft.Build*.dll) from xbuild_12 profile, whereas it didn't work like that (loaded Microsoft.Build.Tasks.dll just from the framework directory for any purpose because Microsoft.Build.Tasks.v12.0.dll is not Microsoft.Build.Tasks.v4.0.dll). If that matches what you expected, then it may fix the problem at your hand.
In not-very-far future xbuild will switch to Microsoft's open-sourced MSBuild assemblies (another mono hacker is working on it) and this kind of xbuild-specific issues would just go away...
I actually just tried testing FCS without the v12 assemblies (i.e. reverting to the old behaviour) and the tests passed (except for some string comparisons involving v12). This does include a test fsproj with ToolsVersion
set to 12, so the situation is definitely improved. This is with Mono 4.0.1 on Linux.
@tpetricek does removing the dependency on this specific version strike you as a useful approach? Every machine should have these only versions of MSBuild from when it was installed with the framework.
@atsushieno just to clarify, when you say that you are surprised that we reference the non-framework v12 assemblies here, why is it OK for xbuild 12 to do the same? Is this only because you give binding redirects, so that Xamarin.Android.Build.Tasks (for example) uses the v12 Task class?
I was not suprised, but anyways... For xbuild, xbuild_12 assemblies are themselves. They reside in the same framework directory. We don't reference v12 task classes in Xamarin.Android.Build.Tasks. It is based on .NET 4.5 profile.
@rneatherway Did you have a test app that you were using to run tests? Perhaps that could be requisitioned to solve the remaining issue of executing in another process?
@7sharp9: I have an app here: https://github.com/rneatherway/msbuildresolution
Can we close this now?
FCS output:
xbuild output: