GetProjectOptionsFromProjectFile` doesn't work for android projects #342
Comments
|
The error is here: 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 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 mono/mono@80093e6 |
|
I cant expect a redirect to be added to |
|
Yeah, I understand that, that's why I'm wondering how xbuild handles it so we can emulate that. Maybe @atsushieno could help. If |
|
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 |
|
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 |
|
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 |
|
@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. |
|
#343 Doesn't fix this issue as we need to invoke this functionality out of process, until then this will be broken. |
Set boundary for Console.CursorTop (fix fsharp#168)
|
@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:
The text was updated successfully, but these errors were encountered: