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
…fsproj into MonoDevelop We can now bootstrap the compiler with xbuild, though it is not the default The compiler projec files can also be loaded into MonoDevelop though it is slow and blocks the UI often (too much garbage being produced? is MonoDevelop using SGEN?). Added an all-vs2010.sln which can be loaded into MD This removes .NET 2.0 as a target for the compiler binaries whcih makes everything simpler (the library binaries for .NET 2.0 are still compiled)
…gets We weren't rebuilding when a resouce changed. Copy from Microsoft.CSharp.targets