Monday, December 14, 2009

Using a different mscorlib for F# in Visual Studio (Silverlight and probably XNA too)

It turns out that I was lucky last year when building an F# Silverlight 2 application by hand in Visual Studio -- I didn't make an explicit reference to mscorlib.

If you explicitly browse to the Silverlight mscorlib assembly to make an explicit reference, the .fsproj file still only gets the basic

    <Reference Include="mscorlib"/>

which falls back to the full framework version of the assembly when you compile. This behaviour has caused some people to abandon the exercise of getting F# to build against something non-default in Visual Studio.

However, the way forward is very simple indeed -- simply edit the .fsproj to give an explicit hint path pointing at the mscorlib you really mean:

    <Reference Include="mscorlib">
      <HintPath>C:\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v3.0\mscorlib.dll</HintPath>
    </Reference>

and get the confirmation that this sticks in the command line that echoes to the Output window

C:\Program Files\FSharp-1.9.7.8\\bin\fsc.exe -o:obj\Debug\Library3.dll -g --debug:full --noframework --define:DEBUG --define:TRACE --optimize- --tailcalls- -r:"C:\Program Files\FSharp-1.9.7.8\Silverlight\2.0\bin\FSharp.Core.dll" -r:"C:\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v3.0\mscorlib.dll" --target:library --warn:3 --warnaserror:76 --vserrors --utf8output --fullpaths --flaterrors Module1.fs

Problem sorted.

(Generalise as required to any other assemblies which refuse to stay pointed at the platform you want.)

Save the version number in the output, this advice is unchanged by the February 2010 CTP.

Post a Comment