Fix compatibility with F# 3.1

[ovatsus]

Code compiled with VS2013 that used FSharp.Data wasn't working because FSharp.Data still targets F# 3.0. Now we detect that case and also replace the FSharp.Core reference like we do for portable class libraries and silverlight (works even if FSharp.Data.DesignTime.dll is compiled in VS2012)

WIP - XmlProvider still is not working, probably still misses a ToDesignTime somewhere, as in this scenario even in full framework we replace assemblies (silverlight didn't support xml, so the problems are probably there since ever). But at least it now fails at compile time instead of at runtime

[tpetricek]

Cool! Thanks for looking into this - just to make sure I get it, in which case is this needed?

• When you have FSharp.Data.dll & FSharp.Data.DesignTime.dll compiled with F# 3.0 but you load them in Visual Studio 2013?
• Or when you compile FSharp.Data.DesignTime.dll with F# 3.1 (to be used in VS 2013), but still have FSharp.Data.dll using just 3.0? (or is FSharp.Data.dll also 3.1?)

(The pull request is looking good to me, just trying to understand what is happening :-))

[ovatsus]

As long as we keep FSharp.Data targeting FSharp.Core 4.3.0.0, it's irrelevant if it's compiled with VS2012 or VS2013, for both runtime and design time assemblies (I even compared the generated il with ildasm and it's exactly the same)

The problem is when someone is using VS2013 for its projects and wants to use FSharp.Data. In this scenario, FSharp.Data.DesignTime.dll is loaded inside the F# 3.1 compiler and that's what causes problems. This can be reproduced by building the tests solution with VS2013 (regardless of what version was used to compile the main solution). These changes fix this scenario by treating it as a cross compilation. Which means we have to load both versions of FSharp.Core and replace the references, which is only possible when loafing in the ReflectionOnly mode, otherwise Assembly.LoadFrom fails, etc, etc...

All of this assuming that even using VS2013 the code is still targeting 4.3.0.0. To be able to support 4.3.1.0, we'll have to have a version of the runtime assembly also targeting it (the design time assembly can stay as is). This will be tricky because NuGet only knows about .Net 4.0/4.5 platforms, it doesn't know the difference between 4.0/FS30 4.0/FS31 4.5/FS0 4.5/FS31. So we'll probably have to have two separate NuGet packages. @dsyme, any guidance on what should be the best practice here?

Alternatively, we could just update everything to target FSharp.Core 4.3.1.0 and we wouldn't need any of this, but that would mean F# 3.0 would no longer be supported.

---

From: Tomas Petricek
Sent: 16/09/2013 05:30
To: fsharp/FSharp.Data
Cc: Gustavo Guerra
Subject: Re: [FSharp.Data] Fix compatibility with F# 3.1 (#203)

Cool! Thanks for looking into this - just to make sure I get it, in which case is this needed?

• When you have FSharp.Data.dll & FSharp.Data.DesignTime.dll compiled with F# 3.0 but you load them in Visual Studio 2013?
• Or when you compile FSharp.Data.DesignTime.dll with F# 3.1 (to be used in VS 2013), but still have FSharp.Data.dll using just 3.0? (or is FSharp.Data.dll also 3.1?)

(The pull request is looking good to me, just trying to understand what is happening :-))

---

Reply to this email directly or view it on GitHub:
#203 (comment)

[ovatsus]

We should also start considering if we should also support the new Portable profile supported by F# 3.1

[tpetricek]

Oh man, that's messy. Thanks for the clarification & great work on finding the workaround!

• I do think supporting F# 3.0 is quite important.
• I would not mind if the only "portable" support was for the new portable profile in 3.1 (if that makes things easier)