Embed MSBUILD dependencies in the package #338

tpetricek · 2015-04-29T13:41:45Z

This is work-in-progress PR for #337.

This correctly copies the binaries to the bin/net45 folder, but for some reason, it does not do the same for the build in bin/net40.

@dsyme @7sharp9 Do you have any idea why the change would not affect the net40 build? Am I missing another fsproj file somewhere :-)?

dsyme · 2015-04-29T14:01:34Z

Looks like you'd need to do these ones too: https://github.com/fsharp/FSharp.Compiler.Service/pull/338/files#diff-d81cb596fee05d911235bc8c0730075bR599

tpetricek · 2015-04-29T14:41:46Z

OK, now it should all work!

tpetricek · 2015-05-24T11:32:46Z

This is now ready to merge and release - @dsyme - could you please do that?

This is coming up in another context - when you have just VS 2015, you do not have the versions of MSBUILD libraries required by the F# Compiler Service (see tpetricek/Dojo-Suave-FsHome#3), so it would be good to have a new release of F.C.S that fixes this :-)

7sharp9 · 2015-05-24T12:36:26Z

It would be nice to decouple msbuild entirely and replicate the project options manually, especially as the msbuild reference resolution can take several seconds.

On 24 May 2015, at 12:32, Tomas Petricek [email protected] wrote:

This is now ready to merge and release - @dsyme - could you please do that?

This is coming up in another context - when you have just VS 2015, you do not have the versions of MSBUILD libraries required by the F# Compiler Service (see tpetricek/Dojo-Suave-FsHome#3), so it would be good to have a new release of F.C.S that fixes this :-)

—
Reply to this email directly or view it on GitHub.

rneatherway · 2015-05-24T13:38:26Z

Sorry I missed this PR before, but I wonder what effect bundling the
windows msbuild assemblies will have on mono? Perhaps we could use a single
unified code path (new api) in that case?

Dave, what exactly do you propose? I'm not sure how we can guarantee to
give the same behaviour as the build except by using msbuild here. I do
accept that the msbuild dependency is rather heavyweight for what it gives,
but I also think that capability is very useful.
On 24 May 2015 13:36, "Dave Thomas" [email protected] wrote:

It would be nice to decouple msbuild entirely and replicate the project
options manually, especially as the msbuild reference resolution can take
several seconds.

On 24 May 2015, at 12:32, Tomas Petricek [email protected]
wrote:

This is now ready to merge and release - @dsyme - could you please do
that?

This is coming up in another context - when you have just VS 2015, you
do not have the versions of MSBUILD libraries required by the F# Compiler
Service (see tpetricek/Dojo-Suave-FsHome#3), so it would be good to have a
new release of F.C.S that fixes this :-)

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#338 (comment)
.

dsyme · 2015-05-26T21:14:25Z

Yes, I'm nervous about the impact of deploying all these DLLs too in various scenarios. It's risky. Tomas, how much validation have you done of the solution? For example, is it still possible to crack project files when things like Microsoft.Common.targets is not on the machine? I'd imagine not. But equally we don't really want to include that as part of the FCS package. So it seems there is still some loss of functionality on target machines.

If we're trying to avoid outright crashes, then the alternative technique is to make sure that the MSBuild dependencies are only exercised on very specific pathways, e.g. when non-explicit references are used like #r "System.Runtime". Many uses of FCS use only fully explicit references (where no use of MSBuild should logically speaking be required, though the DLLs are still actually required today)

I'm not sure what the best and safest solution is. At least, I think we should do a bit more work to quantify what will work and what won't. In the meantime I suppose we can give advice to people to manually deploy the MSBuild binaries in situations where the target machine is not a dev machine.

7sharp9 · 2015-05-26T21:52:54Z

In the case of the build machines at xamarin we had to get msbuild12 deployed to the build server because of the FCS dependency. I think it just needs to be noted quite clearly. I would advise against packaging like this for what is just a single feature of FCS.

On 26 May 2015, at 22:14, Don Syme [email protected] wrote:

Yes, I'm nervous about the impact of deploying all these DLLs too in various scenarios. It's risky. Tomas, how much validation have you done of the solution? For example, is it still possible to crack project files when things like Microsoft.Common.targets is not on the machine? I'd imagine not. But equally we don't really want to include that as part of the FCS package. So it seems there is still some loss of functionality on target machines.

If we're trying to avoid outright crashes, then the alternative technique is to make sure that the MSBuild dependencies are only exercised on very specific pathways, e.g. when non-explicit references are used like #r "System.Runtime". Many uses of FCS use only fully explicit references (where no use of MSBuild should logically speaking be required, though the DLLs are still actually required today)

I'm not sure what the best and safest solution is. At least, I think we should do a bit more work to quantify what will work and what won't. In the meantime I suppose we can give advice to people to manually deploy the MSBuild binaries in situations where the target machine is not a dev machine.

—
Reply to this email directly or view it on GitHub.

rojepp · 2015-05-26T22:35:20Z

I love this quote: "So far, the only thing I really do not like [about F#] is msbuild. How did that barf sandwich ever make it out of alpha?"
http://www.reddit.com/r/fsharp/comments/377ih0/what_i_dislike_about_f/
:)

dsyme · 2015-05-26T23:26:39Z

@7sharp9 - there are two features that depend on MSBuild

MSBuild-style reference resolution used by scripts and "non-simpleresolution" command line compilation/processing.
FSharpChecker project file cracking via GetProjectOptionsFromCommandLineArgs/GetProjectOptionsFromProjectFile/GetProjectOptionsFromScript.

Feature 1 is the one that Tomas (and transitive users of FSharp.Formatting) are hitting. Further I think this feature causes a hard dependency on the MSBuild binaries even if it is not actually used (i.e. if "simpleresolution" is used)

To explain in further detail.... Feature 1 lets #r in scripts and command line -r references use text like "System.Runtime" or "System.Xml" (without ".dll"), or versioned full assembly names like "System.Xml, Version=...." using a full assembly name. It also searches some "standard" installation locations like ReferenceAssemblies also the GAC in addition to #I paths.

Feature 1 is used by F# Interactive and FsiInteractiveSession when processing scripts. In practice very many scripts rely on it, though mostly because people drop off the ".dll" from a reference name. It's also used by invocations to the F# compiler that do not pass "--simpleresolution", though those are much rarer and less important since any compilation coming from Xamarin Studio or Visual Studio does full resolution in the IDE based on project file settings and passes "--simpleresolution".

In the implementation Feature 1 relies on MSBuild's capabilities to do reference resolution (in contrast --simpleresolution does resolution "manually" by looking through search paths). Feature 1 is not even enabled on Mono systems where "simple resolution" is used all the time. However this is regarded as an important discrepancy that needs to be resolved), see also this

One path would be to just disable Feature 1 completely for the nuget-shipped FSharp.Compiler.Service - i.e. require that simple resolution be used. However this would give discrepancies in script reference resolution on Windows, and wouldn't place us on a path to good convergence. Alternatively we could seek to completely re-implement the relevant part of the reference resolution code (perhaps with an option to use MSBuild reference, inducing a runtime dependency on the DLLs, just in case there are discrepancies - I can see that being attractive to the Visual F# Tools, for example, when they move to use FCS).

Feature 2 uses MSBuild's ability to crack and process project files. My understanding is that feature 2 is just not going to work easily without an appropriate install of MSBuild - processing project files naturally requires all the relevant .targets to be installed. I think it's reasonable to expect MSBuild to be installed in those scenarios (though we should document exactly which version needs to be installed and why in a design note similar to the one on FSharp.Core)

As a first step, it would be good to remove the hard dependency on MSBuild for reference resolution in the case where --simpleresolution is passed.

Finally, I should add that I find the way FSharp.Formatting is driving FSharp.Compiler.Service a bit hard to unpick - the various "generate.fsx" files I've seen seem to be doing some reference resolution themselves, and in a somewhat adhoc way, and may be relying on the "non-simple" reference resolution feature (Feature 1 above) much more than any other client. For "generate.fsx" documentation generation I think I'd prefer the reference resolution to be done using the more standard "crack a project file" or "crack a script" rather than the adhoc "throw some text for some references at FCS and cross your fingers" approach that seems to be commonplace right now. I'm not sure about other clients of FCS besides these "generate.fsx" scripts though, it would be good to get a grip on how widespread the use of Feature 1 is.

7sharp9 · 2015-05-26T23:29:38Z

Feature 1 needs the older version of msbuild, feature 2 needs the newer one, version 12 I believe which results in the new references which are now needed.

dsyme · 2015-05-26T23:34:07Z

@7sharp9 - can you adjust your comment above to give the exact version numbers (DLL version numbers) you mean when you say "older" and "newer" versions of MSBuild. Also, I think this thread is about allowing basic compilation, checking and script processing functionality of FCS to be used without any version of MSBuild installed (i.e. if Feature 1 and Feature 2 are not used at all)

7sharp9 · 2015-05-26T23:37:34Z

Ill find out when I get a minute about the versions. The point I was making was feature 2 added new dependencies on a newer msbuild, which required installing a seperate package on the build server.

tpetricek · 2015-05-27T04:05:16Z

I do not understand all the implications here.

It might not be such a big issue, but I got back to this because of the issue raised here: tpetricek/Dojo-Suave-FsHome#3. Is there another solution to that issue? (If no, it means that F# Compiler Service only works when you have VS 2013 installed, which sounds wrong.)

7sharp9 · 2015-05-27T08:23:51Z

@tpetricek msbuild is installed separately from the .Net framework, so if you were referencing one more recent than whatever was shipped with vs2013 then you might expect to have to install it.

7sharp9 · 2015-05-27T08:25:36Z

If FCS does not work without a newer msbuild then that might mean that Xamarin Studio now has a dependency on a later msbuild being installed too.

rneatherway · 2015-05-27T08:58:55Z

@dsyme thanks for the thorough explanation. I was only vaguely aware of "Feature 1" as I'm focused on "Feature 2" which is an important facility for FSharp.AutoComplete. I think this issue might well be traced back to the inclusion of Feature 2 (8249ee6)
though, specifically when we changed to depend on new MSBuild in order that the cracking worked on Mono (96a5f32):

--- a/src/fsharp/FSharp.Compiler.Service/FSharp.Compiler.Service.fsproj
+++ b/src/fsharp/FSharp.Compiler.Service/FSharp.Compiler.Service.fsproj
@@ -596,11 +596,17 @@
     <Reference Include="System" />
     <Reference Include="System.Core" />
     <Reference Include="System.Xml" />
-    <Reference Include="Microsoft.Build.Framework" />
-    <Reference Include="Microsoft.Build.Engine" />
-    <Reference Include="Microsoft.Build" />
-    <Reference Include="Microsoft.Build.Utilities.v4.0" />
-    <Reference Include="Microsoft.Build.Tasks.v4.0" />
+    <Reference Include="Microsoft.Build.Framework" Condition=" '$(TargetFrameworkVersion)' == 'v4.0'" />
+    <Reference Include="Microsoft.Build.Engine" Condition=" '$(TargetFrameworkVersion)' == 'v4.0'" />
+    <Reference Include="Microsoft.Build" Condition=" '$(TargetFrameworkVersion)' == 'v4.0'" />
+    <Reference Include="Microsoft.Build.Utilities.v4.0" Condition=" '$(TargetFrameworkVersion)' == 'v4.0'" />
+    <Reference Include="Microsoft.Build.Tasks.v4.0" Condition=" '$(TargetFrameworkVersion)' == 'v4.0'" />
+    
+    <Reference Include="Microsoft.Build.Framework, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" />
+    <Reference Include="Microsoft.Build.Engine, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" />
+    <Reference Include="Microsoft.Build, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" />
+    <Reference Include="Microsoft.Build.Utilities.v12.0" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" />
+    <Reference Include="Microsoft.Build.Tasks.v12.0" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" />
     <Reference Include="FSharp.Core, Version=$(TargetFSharpCoreVersion), Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
       <Private>False</Private>
     </Reference>

Before VS2012, I think MSBuild was bundled with .NET, so most machines can be expected to have the 4.0.0.0 version of MSBuild. Before the diff above therefore the MSBuild assemblies in the GAC would have been used.

A later change (306e478) added SpecificVersion:

-    <Reference Include="Microsoft.Build.Framework, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" />
-    <Reference Include="Microsoft.Build.Engine, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" />
-    <Reference Include="Microsoft.Build, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" />
+    <Reference Include="Microsoft.Build.Framework, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" >
+        <SpecificVersion>True</SpecificVersion>
+    </Reference>
+    <Reference Include="Microsoft.Build.Engine, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" >
+        <SpecificVersion>True</SpecificVersion>
+    </Reference>
+    <Reference Include="Microsoft.Build, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" >
+        <SpecificVersion>True</SpecificVersion>
+    </Reference>

I am a bit unsure of the semantics of this tag. Does it mean no later version, whereas that is normally allowed? In the issue linked by Tomas, the user had VS2015 installed, which surely comes with some more advanced version of MSBuild, so perhaps this tag prevented use of the VS2015 MSBuild assemblies?

If we want to bundle, which might be a good idea, I'm not sure yet, then I can test that bundling .NET MSBuild works on Linux/OSX.

I do think that MSBuild should be provided as a NuGet package. There actually is a recently created package at https://www.nuget.org/packages/MSBuild/, but I'm not sure if the maintainer is connected with the project.

@rojepp I agree, but I guess we are where we are.

7sharp9 · 2015-05-27T09:06:31Z

No one likes msbuild but unfortunately until someone re-writes what it provides for us we have to use it. Luckily its open source so we can see the source. AFAIK the latest mono has msbuild14

Interestingly Roslyn has a hard dependency on msbuild14 too.

dsyme · 2015-05-27T21:49:45Z

@tpetricek Probably the simplest interim solution is for you to push a nuget package ("FSharp.Compiler.Service.Dependencies"?) containing the MSBuild binaries (and an .fsx script to load/reference them). Then add that as a dependency to those projects/samples using FSharp.Compiler.Service delivered to non dev machines.

dsyme · 2015-05-27T21:57:07Z

@rneatherway Yes, I think you're right.

We need a list of what versions of the MSBuild SDK binaries are made available by which versions of Mono/VS/WindowsSDK. It seems:

MSBuild 4.0.0.0 - Widely available as bundled with .NET 4.x
MSBuild 12.0.0.0 - Installed with Visual Studio 2013 (actually the Windows SDK?)
MSBuild 14.0.0.0 - Installed with Visual Studio 2015 (actually the Windows SDK?)

But what about Mono?

cheers
don

rneatherway · 2015-05-28T08:57:57Z

This is the current situation:

Mono JIT compiler version 4.0.1 (tarball Tue Apr 28 11:47:58 UTC 2015)
$ gacutil -l Microsoft.Build
Microsoft.Build, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Microsoft.Build, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Microsoft.Build, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Number of items = 3

I'm not sure if MSBuild 14 is the MS open-source release. It would be great if so.

Another possibility is to add a binding redirect to FCS from MSBuild 12 up to 14. Is it possible to do that for a library, if not we could recommend it for applications that use FCS, as with your note on FSharp.Core. That note is incredibly useful btw.

dsyme · 2015-05-28T23:27:37Z

@rneatherway Thanks for the info. (Do you know which Linux package has the MSBuild DLLs? I presume it's not in the "minimal" mono runtime installation, but is in "mono-devel"?)

The binding redirects (or a runtime assembly binding using Assembly Load Event?) are an interesting possibility

dsyme · 2015-05-29T00:11:54Z

@rneatherway Could you also show the gacutil -l for Microsoft.Build.Framework please? (I assume is that on Linux?)

I notice MSBuild.exe.config on Windows has the following binding redirects (and so does devenv.exe.config), so it certainly is valid to use binding redirects for these assemblies.

        <dependentAssembly>
            <assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
            <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="14.0.0.0"/>
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.Build.Engine" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
            <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="14.0.0.0"/>
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.Build" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
            <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="14.0.0.0"/>
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.Build.Conversion.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
            <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="14.0.0.0"/>
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.Build.Tasks.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
            <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="14.0.0.0"/>
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.Build.Utilities.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
            <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="14.0.0.0"/>
        </dependentAssembly>

rneatherway · 2015-05-29T09:09:00Z

@dsyme it is really split up amongst a bunch of packages.

$ dpkg -S Microsoft.Build | cut -d':' -f1 | sort -u
libmono-microsoft-build4.0-cil
libmono-microsoft-build-engine4.0-cil
libmono-microsoft-build-engine4.0-cil, mono-xbuild
libmono-microsoft-build-framework4.0-cil
libmono-microsoft-build-tasks-v4.0-4.0-cil
libmono-microsoft-build-utilities-v4.0-4.0-cil
mono-devel
mono-xbuild

It's pretty strange, the full breakdown is:

$ dpkg -S Microsoft.Build*dll | sort
libmono-microsoft-build4.0-cil: /usr/lib/mono/4.5/Microsoft.Build.dll
libmono-microsoft-build4.0-cil: /usr/lib/mono/gac/Microsoft.Build/4.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.dll
libmono-microsoft-build-engine4.0-cil: /usr/lib/mono/4.5/Microsoft.Build.Engine.dll
libmono-microsoft-build-engine4.0-cil: /usr/lib/mono/gac/Microsoft.Build.Engine/4.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Engine.dll
libmono-microsoft-build-framework4.0-cil: /usr/lib/mono/4.5/Microsoft.Build.Framework.dll
libmono-microsoft-build-framework4.0-cil: /usr/lib/mono/gac/Microsoft.Build.Framework/4.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Framework.dll
libmono-microsoft-build-tasks-v4.0-4.0-cil: /usr/lib/mono/4.5/Microsoft.Build.Tasks.v4.0.dll
libmono-microsoft-build-tasks-v4.0-4.0-cil: /usr/lib/mono/gac/Microsoft.Build.Tasks.v4.0/4.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Tasks.v4.0.dll
libmono-microsoft-build-utilities-v4.0-4.0-cil: /usr/lib/mono/4.5/Microsoft.Build.Utilities.v4.0.dll
libmono-microsoft-build-utilities-v4.0-4.0-cil: /usr/lib/mono/gac/Microsoft.Build.Utilities.v4.0/4.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Utilities.v4.0.dll
mono-devel: /usr/lib/mono/2.0/Microsoft.Build.Engine.dll
mono-devel: /usr/lib/mono/2.0/Microsoft.Build.Framework.dll
mono-devel: /usr/lib/mono/2.0/Microsoft.Build.Tasks.dll
mono-devel: /usr/lib/mono/2.0/Microsoft.Build.Utilities.dll
mono-devel: /usr/lib/mono/3.5/Microsoft.Build.Engine.dll
mono-devel: /usr/lib/mono/3.5/Microsoft.Build.Framework.dll
mono-devel: /usr/lib/mono/3.5/Microsoft.Build.Tasks.v3.5.dll
mono-devel: /usr/lib/mono/3.5/Microsoft.Build.Utilities.v3.5.dll
mono-devel: /usr/lib/mono/4.0/Microsoft.Build.dll
mono-devel: /usr/lib/mono/4.0/Microsoft.Build.Engine.dll
mono-devel: /usr/lib/mono/4.0/Microsoft.Build.Framework.dll
mono-devel: /usr/lib/mono/4.0/Microsoft.Build.Tasks.v4.0.dll
mono-devel: /usr/lib/mono/4.0/Microsoft.Build.Utilities.v4.0.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build/12.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build/14.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build.Engine/12.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Engine.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build.Engine/14.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Engine.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build.Framework/12.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Framework.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build.Framework/14.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Framework.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build.Tasks.Core/14.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Tasks.Core.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build.Tasks.v12.0/12.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Tasks.v12.0.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build.Utilities.Core/14.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Utilities.Core.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build.Utilities.v12.0/12.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Utilities.v12.0.dll
mono-xbuild: /usr/lib/mono/xbuild/12.0/bin/Microsoft.Build.dll
mono-xbuild: /usr/lib/mono/xbuild/12.0/bin/Microsoft.Build.Engine.dll
mono-xbuild: /usr/lib/mono/xbuild/12.0/bin/Microsoft.Build.Framework.dll
mono-xbuild: /usr/lib/mono/xbuild/12.0/bin/Microsoft.Build.Tasks.v12.0.dll
mono-xbuild: /usr/lib/mono/xbuild/12.0/bin/Microsoft.Build.Utilities.v12.0.dll
mono-xbuild: /usr/lib/mono/xbuild/14.0/bin/Microsoft.Build.dll
mono-xbuild: /usr/lib/mono/xbuild/14.0/bin/Microsoft.Build.Engine.dll
mono-xbuild: /usr/lib/mono/xbuild/14.0/bin/Microsoft.Build.Framework.dll
mono-xbuild: /usr/lib/mono/xbuild/14.0/bin/Microsoft.Build.Tasks.Core.dll
mono-xbuild: /usr/lib/mono/xbuild/14.0/bin/Microsoft.Build.Utilities.Core.dll

So MSBuild versions:

.NET < 4.5: Provided by mono-devel, placed under /usr/lib/mono/$FRAMEWORK, not symlinked to GAC
.NET = 4.5: Provided by libmono-microsoft-build*. Placed in /usr/lib/mono/4.5, symlinked to the GAC versions 4.0.0.0
(VS) 12 and 14: Provided by mono-xbuild, placed in /usr/lib/mono/xbuild/$VSVERSION/bin, symlinked to corresponding GAC versions.

rneatherway · 2015-05-29T09:09:49Z

Also:

$ gacutil -l Microsoft.Build.Framework
The following assemblies are installed into the GAC:
Microsoft.Build.Framework, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Microsoft.Build.Framework, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Microsoft.Build.Framework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Number of items = 3

rneatherway · 2015-05-29T09:12:34Z

The xbuild.exe that gets called by /usr/bin/xbuild has a similar redirect:

$ cat /usr/lib/mono/xbuild/12.0/bin/xbuild.exe.config 
<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <runtime>
        <generatePublisherEvidence enabled="false" />
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
                <bindingRedirect oldVersion="0.0.0.0-100.0.0.0" newVersion="12.0.0.0" />
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Build.Engine" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
                <bindingRedirect oldVersion="0.0.0.0-100.0.0.0" newVersion="12.0.0.0" />
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>

The one under 14.0 redirects to the 14.0 assemblies, but it isn't the default yet.

I think that understanding and addressing this issue may allow us to resolve #342 as well.

tpetricek · 2015-05-29T22:48:44Z

I changed the PR so that it builds a separate package (FSharp.Compiler.Service.Standalone) rather than changing the existing one to include the MSBUILD assemblies. Let me know if this sounds like a good option for now.

Doing this is still not optimal, because I'm not sure what you'd do if you wanted to use, say F# Formatting (which has FCS dependency) but with FCS.Standalone. But it at least gives us a starting point that we can use for the web scenarios.

Having FCS.Lightweight without MSBUILD dependencies would be even cooler though. We could certainly change F# Formatting to use that instead.

rneatherway · 2015-06-29T14:00:24Z

I think we should probably go ahead and merge this. As it adds a new package it seems fairly harmless, and it has cropped up elsewhere as well. The more people have VS2015 installed and not VS2013 the worse it will get.

rojepp · 2015-06-29T14:23:01Z

Wouldn't that just lead to errors with missing *.targets files?

rneatherway · 2015-06-29T14:31:22Z

Hmm, do you think the VisualStudioVersion will cause it to look in a non-existent place? Troubling. This is a nightmare. I can't easily create a machine with just VS2015 either.

dsyme · 2015-06-30T13:56:57Z

I'd prefer not to merge as is, at least not yet. Adding another nuget package to FCS which includes MSBuild binaries makes the FCS project responsible for distributing a bunch of MSBuild binaries in a non-standard configuration. This seems like the wrong direction without really extensive testing of the functionality this does/doesn't enable (see these two features - as I understand it the PR doesn't really enable either feature) . From past experience, if we add an extra nuget package it will be years before we remove it.

That said, we certainly have a real problem here and we need to document it and enable a workaround.

@tpetricek - do you think you can do as I suggested here and create a separate package (in a separate repo) that provides the MSBuild binaries? Then submit a guide like this one which explains what the MSBuild dependencies are and how to use the interim package to avoid having a specific version of MSBuild on the target machine?

@rneatherway - another option is that we reflection-bind to MSBuild - either V4.0 or v12.0, so we have no static dependencies to MSBuild at all. If no MSBuild is bindable then feature 1 "reference resolution" falls back to simple resolution, and feature 2 "Project Cracking" fails with an informative exception. We could test both scenarios via fault injection.

Thanks,
Don

7sharp9 · 2015-06-30T14:05:47Z

Theres still underlying issues with project cracking too, the whole operation needs to be done via a separate process to support redirecting msbuild tasks to the right version.

Added backticks around the git commands in README.md to format them properly

dsyme · 2015-12-02T00:53:48Z

Closing as we now have #470

Embed MSBUILD dependencies in the package

91ba670

tpetricek force-pushed the master branch from 633754d to 91ba670 Compare April 29, 2015 14:32

tpetricek changed the title ~~[WiP] Embed MSBUILD dependencies in the package~~ Embed MSBUILD dependencies in the package May 24, 2015

Produce separate standalone package

134c928

rneatherway mentioned this pull request Jun 11, 2015

Add fix for #343 Use ResolveReferences task #345

Merged

rneatherway mentioned this pull request Jul 6, 2015

error fsprojects/zarchive-sublime-fsharp-package#75

Open

ovatsus pushed a commit to ovatsus/FSharp.Compiler.Service that referenced this pull request Jul 12, 2015

Merge pull request fsharp#338 from ipavl/master

e30b237

Added backticks around the git commands in README.md to format them properly

dsyme closed this in 52e6e03 Jul 31, 2015

rneatherway reopened this Jul 31, 2015

dsyme closed this Dec 2, 2015

tpetricek mentioned this pull request Oct 3, 2016

FSharp.Compiler.Service dependency on MSBuild #631

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Embed MSBUILD dependencies in the package #338

Embed MSBUILD dependencies in the package #338

tpetricek commented Apr 29, 2015

dsyme commented Apr 29, 2015

tpetricek commented Apr 29, 2015

tpetricek commented May 24, 2015

7sharp9 commented May 24, 2015

rneatherway commented May 24, 2015

dsyme commented May 26, 2015

7sharp9 commented May 26, 2015

rojepp commented May 26, 2015

dsyme commented May 26, 2015

7sharp9 commented May 26, 2015

dsyme commented May 26, 2015

7sharp9 commented May 26, 2015

tpetricek commented May 27, 2015

7sharp9 commented May 27, 2015

7sharp9 commented May 27, 2015

rneatherway commented May 27, 2015

7sharp9 commented May 27, 2015

dsyme commented May 27, 2015

dsyme commented May 27, 2015

rneatherway commented May 28, 2015

dsyme commented May 28, 2015

dsyme commented May 29, 2015

rneatherway commented May 29, 2015

rneatherway commented May 29, 2015

rneatherway commented May 29, 2015

tpetricek commented May 29, 2015

rneatherway commented Jun 29, 2015

rojepp commented Jun 29, 2015

rneatherway commented Jun 29, 2015

dsyme commented Jun 30, 2015

7sharp9 commented Jun 30, 2015

dsyme commented Dec 2, 2015

Embed MSBUILD dependencies in the package #338

Embed MSBUILD dependencies in the package #338

Conversation

tpetricek commented Apr 29, 2015

dsyme commented Apr 29, 2015

tpetricek commented Apr 29, 2015

tpetricek commented May 24, 2015

7sharp9 commented May 24, 2015

rneatherway commented May 24, 2015

dsyme commented May 26, 2015

7sharp9 commented May 26, 2015

rojepp commented May 26, 2015

dsyme commented May 26, 2015

7sharp9 commented May 26, 2015

dsyme commented May 26, 2015

7sharp9 commented May 26, 2015

tpetricek commented May 27, 2015

7sharp9 commented May 27, 2015

7sharp9 commented May 27, 2015

rneatherway commented May 27, 2015

7sharp9 commented May 27, 2015

dsyme commented May 27, 2015

dsyme commented May 27, 2015

rneatherway commented May 28, 2015

dsyme commented May 28, 2015

dsyme commented May 29, 2015

rneatherway commented May 29, 2015

rneatherway commented May 29, 2015

rneatherway commented May 29, 2015

tpetricek commented May 29, 2015

rneatherway commented Jun 29, 2015

rojepp commented Jun 29, 2015

rneatherway commented Jun 29, 2015

dsyme commented Jun 30, 2015

7sharp9 commented Jun 30, 2015

dsyme commented Dec 2, 2015