Following the announcement that F# and the Iron languages are being bundled with Mono 2.10 for Mac and Linux, I thought it worth taking the system for a spin on Windows as well. This is a record of my experiments, and are nowhere near a complete HOW-TO as yet (they more closely resemble a HOW NOT TO at the moment).
The easy bit is as per Zor's blog, here --
- Get the mono strong-name key
- Now this is voodoo -- without going
& 'C:\Program Files\Mono-2.10\bin\sn.bat' -R .\FSharp.Core.dll .\mono.snkon a copy of the F# runtime, the GACing step fails : yet the operation doesn't actually change the embedded key (going as far as
ILAsmseems a bit extreme!)
- As administrator,
& 'C:\Program Files\Mono-2.10\bin\mono.exe' 'C:\Program Files\Mono-2.10\lib\mono\2.0\gacutil.exe' -i '.\FSharp.Core.dll', and then copy the original
C:\Program Files\Mono-2.10\lib\mono\3.5\Microsoft.Common.targetsundo the commenting out of
- In the copy of the
Microsoft.Sharp.targetsfile, comment out the
<ItemGroup Remove="...">clauses after
Fsctask in the
CoreCompiletarget, and the two in
CreateManifestResourceNames(might there be a
CreateItemequivalent? Haven't tried yet).
At this point, pure F# projects for VS2008 will build happily, so long as you don't have any fancy modern task attributes in
Error executing task Copy: Task does not have property "OverwriteReadOnlyFiles" defined if you try to use that).
Where I have yet to manage to persuade the build process to work is for projects with embedded resources (such as Glade XML definitions for a UI). These yield up
Target CopyNonResxEmbeddedResources: C:\PROGRA~1\Mono-2.10\lib\mono\3.5\Microsoft.Common.targets: error : You must specify DestinationFolder or DestinationFiles attribute. Task "Copy" execution -- FAILED
which may possibly relate to some of the
<ItemGroup Remove="..."> operations not being carried out. Certainly, some more MSBuild hackery will be required to track down what is going on and make sure that both sides of the copy operation match up -- so that either the source is empty, and no copy is attempted, or so that the destination doesn't end up null.
Support for VS2010 projects isn't there yet -- after
sn -R (with equally little effect on the strong-name given by
sn -Tp) and GACing the 4.0 version of FSharp.Core.dll, trying to build a VS2010 project yields up the cryptic message, sometimes as an error, sometimes as a warning, that
"Operation is not valid due to the current state of the object" -- even with
/verbosity:diagnostic turned on no more detail is divulged. And having the 4.0 version GAC'd interferes with the 2.0 version in the GAC -- the later version is selected by preference and then fails for being incompatible with the 2.0-level mscorlib when building a vanilla VS2008 project with just a simple reference (without explicit version information like
<Reference Include="FSharp.Core" />) to the F# runtime.