FSharp.Compiler.CodeDom for VS2008 and VS2010 side-by-side

Question

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

Answer 1

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.

Answer 2

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 :)

Answer 3

I fixed a problem that may or may not have been the same with the reghack (Windows 7): Windows Registry Editor Version 5.00

[-HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\FSharp\2.0\Runtime]

I believe that the resolution path to find files/compilers means that this hack will cause both to work side-by-side, but have only tested the 2.0 case. As with any reg hack, you should back up that that reg key first.