views:

201

answers:

2

I'm using FSharp.Compiler.CodeDom (from the PowerPack) to dynamically create F# classes. The problem is, that I have both VS2008 and VS2010 on my computer side-by-side (they works fine), and using F# in this configuration is buggy at best:

  • If I don't install InstallFSharp.msi, then under VS2008 the built classes complain about not finding FSharp.Core (even if they're referenced)
  • If I install InstallFSharp.msi, then under VS2008 the built classes will use the F# built for VS2010, and will throw a binary-incompatibility exception, because it will load the .net4 variant:

    FSC: error FS0219: The referenced or default base CLI library 'mscorlib' is binary- incompatible with the referenced F# core library 'C:\Program Files (x86)\Microsoft F#\v4.0\FSharp.Core.dll'. Consider recompiling the library or making an explicit reference to a version of this library that matches the CLI version you are using.

  • If I replace the F# found at the previous location to the separately installed dll-s, then of course VS2010 will complain about binary-incompatibility

Am I overlooking something, or they won't simply work for a shared environment like this? This might mean real problems when I deploy the applications.

Thanks

+2  A: 

I have a similar problem myself - the trunk of our source tree is set up to build with VS 2008, while our latest branch upgrades to VS 2010. The F# situation is wearisome, to say the least.

The answer that we've found is to use the --noframework compiler flag. With that option set, you can (must) specify which mscorlib.dll and System.dll you want to use, and therefore can build against any supported .NET framework.

Ben
It seems in F# 2.0 the ImageRuntimeVersion of the generated assembly is v4.0.xxx by default. That changes to v2.0.xxxx when adding a reference to the v2.0 version of mscorlib.dll. This works even if I don't set --noframework, I just have to add the explicit reference.
Govert
Interesting! I get a compiler error if I attempt to -r mscorlib.dll without the --noframework flag. What version of the compiler are you using that allows this?
Ben
Sorry, I think I got it wrong. I'm using the CodeDom.FSharpCodeProvider with CompileAssemblyFromSource(...). It seems they automatically add the --noframework flag (even if I don't reference mscorlib.dll explicitly), so it _is_ actually set when the compiler is invoked, even though I don't set it explicitly in the CompilerOptions. I can see the exact command line in the temp file xxx.cmdargs that the CodeProvider creates.
Govert
this did work for me, so thank you.
SztupY
Yip - I think that's the best explanation we'll get. Thanks Ben.
Govert
+1  A: 

Given that you originally asked the question a while ago, I wonder if you have the most recent PowerPack? Notably, you ask the question on May 27, but I see on the downloads page that it was last updated on May 30. I dunno if that affects anything, just pointing it out.

I also edited the question a tiny bit, in case this moves the question to the top and causes Tomas to see it and reply :)

Brian
Mmmm... I ran into this issue with the latest PowerPack, so I doubt the behaviour has changed. The CodeDom compiler is just badly undocumented, and the compiler switches and defaults changed from previous versions - there used to be a --cli-version switch.
Govert