In case you need a clarification wrt bloat: http://tirania.org/blog/archive/2012/Oct-20.html
See #50 The comments in FSharpBuild/Fsc.fs explain a bit more. It is realy hard to work out how to make this perfectly consistent. Essentially, be careful using resources in folders if you want your projects to be portable across VisualStudio/MSBuild and mono/MonoDevelop/XBuild We hit this bug in fsharp/fsharpbinding, but we've moved that to no longer put resources in folders for now.
switch to strong names for compiler binaries and update the bootstrap compiler with those names. The strong names are based on src\fsharp\test.snk this means the strong name for FSharp.Compiler.dll changes, but no one should be depending on that and the new names are useful as the won't collide with the visual studio versions of these DLLs on windows. The monodevelop binding is neutral to the strong names used. we still compile FSharp.Core as delay-signed-with-the-microsoft-key-and-then-mono-key-signed which Mono recognizes as strong named but i think windows does not. We have to use this identity for FSHarp.Core to keep binary compatibility with Windows-compiled thing like type provider DLLs. We may have to use the Microsoft FSHarp.Core.dll on Windows, i think it gets picked up automatically from the GAC but need to check tomorrow. also fixes bugs in ilsupp.fs in strong nae signing. tested by bootstrapping, and manually examining the names on the dlls.
This ensures mono-sgen is used even if fsc.exe is invoked by xbuild. Aso add tracing diagnostics to /resident startup
…ture);@(ManifestNonResxWithNoCultureOnDisk);@(CompiledLicenseFile);@(DocFileItem); $(KeyOriginatorFile);@(ReferencePath);$(Win32Icon);$(Win32Resource)" Fix "xbuild doesn't detect changes to resource files" Missing dependency in Microsoft.FSharp.targets
… projects with ToolsVersion=3.5 build a 2.0 FSharp.Build.dll and reference it