F# Option goes bonkers when copying the solution to a different location - visual-studio-2010

Question

This is extremely strange, and I'm hoping someone will have some insights to make sense of this.
I have an F# 2.0 (Visual Studio 2010, targeting .Net 4.0) solution which works fine in the location where I originally created it, but if I try and copy it to a new folder (because I want to check it in to source control), I get some very odd errors when building. They tend to be along the lines of:
error FS0803: Invalid use of a type name and/or object constructor. If necessary use 'new' and apply the constructor to its arguments, e.g. 'new Type(args)'. Overloads are: None() : unit.
or
error FS0001: This expression was expected to have type obj option but here has type Some<'a>
These errors are only occurring for uses of the option type, a simple example of one such usage being:
let asOption e =
match e with
| null -> None
| _ -> Some(e)
Now, remember, this is a solution that compiles just fine in its original location. I've tried the obvious like Clean/Rebuild, deleting the obj and bin directories, restarting Visual Studion, and still, the same.
The reference DLLs are all the same in both cases, GAC'd DLLs are being referenced from the GAC, non-GAC'd dlls are copied and being referenced from the same relative path. Just for fun, I've even compared the output window text of the calls to Fsc.exe used to compile each solution to ensure the compiler is being called with the same arguments in both cases, and, naturally, it is.
Anyone have any idea of what may be causing this? Am I getting some strange limbo version of FSharp.Core.dll out of the GAC somehow? Am I just the most unlucky of the unlucky stiffs?

Answer 1

So the weird symptom had an equally weird cause.
It turns out one of the DLLs I was referencing (the ubiquitous "Core" junk-drawer dll every project has) must have some extension methods in place that are causing some issues with the type inference used by the compiler and visual studio.
When I remove the open MyProject.Core and replace any of the references to types I'm using with the fully qualified name, the strange errors magically go away.
So, at this point, two questions remain:
What kind of insane extension methods are in there that could be causing this
Why was the original solution/project unaffected by this? (I'm guessing this may be related to the order in which the references were passed into the call to Fsc.exe...but I'm not sure).
I may actually dig in enough to try and figure out the answer to #1. I'm not sure if it is exposing some sort of bug with the F# compiler (doubtful), or if my co-workers are just doing something unnatural with extension methods (highly likely)
UPDATE:
Looks like someone had some F# envy and created an Option<T> class in the Core project. Pretty much explains things. I've not experimented to see if the order of the includes on the Fsc.exe call make a different, but I have a feeling that is it.

Answer 2

References should almost never come from the GAC, they should come from Reference Assemblies. Post the fsc.exe command-line you are witnessing, perhaps it will shed more light. I am guessing the FSharp.Core reference is messed up somehow (perhaps related to the sigdata/optdata files that stand alongside its reference assembly?)
(Points for a very weird symptom, though!)

Answer 3

Assuming F# compiler is deterministic, there obviously must be some difference in how it is being invoked, perhaps in the environment variables. Have you tried running MSBuild from the command line? It usually helps with these kind of things.
One guess of what's going on is that F# infers different types for your code. Have you tried constraining it a bit to only have to deal with simple types? For example:
let asOption (e: obj) =
match e with
| null -> None
| _ -> Some(e)
Or else:
let asOption<'T> (x: 'T) : option<'T> =
if x :> obj = null then None else Some x
The later gets rid of the null constraint on the generic parameter.