Type providers fail when only FSharp.Core 4.3.1.0 is installed

[tpetricek]

If you have a new Windows machine and follow the installation instructions on fsharp.org, you'll end up with a computer that has only FSharp.Core 4.3.1.0. For example:

"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\gacutil.exe" /l FSharp.Core

Microsoft (R) .NET Global Assembly Cache Utility.  Version 4.0.30319.33440
Copyright (c) Microsoft Corporation.  All rights reserved.

The Global Assembly Cache contains the following assemblies:
  FSharp.Core, Version=2.3.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL
  FSharp.Core, Version=4.3.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL

When you then try to use some of the type providers, you get an error akin to:

The type provider 'ProviderImplementation.WorldBankProvider' reported an error: The type provider constructor has thrown an exception: Cannot resolve dependency to assembly 'FSharp.Core, Version=4.3.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.

The solution would be to add binding redirect mapping 4.3.0.0 to 4.3.1.0. But where? If you want to use type providers in VS, do you have to add binding redirect to devenv.exe.config and to fsi.exe.config? Or to machine.config (but what if you have to ask system admin to do this)? Or is there a better solution? (AFAIK, there is no way to install standalone redist of FSharp.Core 4.3.0.0....) Or should the type provider handle this somehow?

Any help would be appreciated!

EDIT: Another attempt to solve this was to add reference to F# 4.3.0.0 NuGet package but that does not help either.

EDIT 2: I have to admit, I absolutely do not understand how versioning of FSharp.Core works these days and how (not) referencing different versions changes what the compiler does. Maybe I'm just stupid, but maybe this is just completely broken (?) if I just cannot understand it...

[ovatsus]

Unless you have FSharp.Data target 4.3.1.0, you really have no way of fixing this... I've spent countless hours after these kinds of problems, but it's a big mess... A couple of days ago I hit the same problem, that's why I added this to the README: 499aa1e

[ptrelford]

Part of the issue here is that Nuget is premised on the idea of delivering package versions based on .Net framework version only. This issue should probably be raised against Nuget.

Workarounds:
(1) Release another FSharp.Data package that binds to 4.3.1.0
(2) Fudge with one FSharp.Data package, with Net40 binding to 4.3.0.0 and Net451 binding to 4.3.1.0

I'd really like to understand what's going wrong here. You should not have to target 4.3.1.0.

devenv.exe, fsc.exe and fsi.exe are all designed to have the correct binding redirects. I checked on my machine and they do.

Anyway, we're now discussing this on fsbugs AT microsoft.com, thanks

[ovatsus]

Just to be sure @tpetricek, this is with FSharp.Data 2.0.x, right?

If you can get a callstack for where the exception is raised in devenv.exe or fsi.exe, that would be useful

[tpetricek]

It was using the latest version of FsLab - which now references F# Data 2.0.0-beta6.

[t0yv0]

Not sure if it helps, but there is a nice little hack I discovered for a similar problem with versions of F# core. This has to be called explicitly in all domains involved in an application. But then - no .exe.config/web.config is needed.

    let SetupRedirects () =
        System.AppDomain.CurrentDomain.add_AssemblyResolve(fun h ev ->
            let name = System.Reflection.AssemblyName(ev.Name)
            if name.Name = "FSharp.Core" then
                typedefof<list<_>>.Assembly
            else
                null)

The problem here is specifically related to a ReflectionOnly load, so you would use:

        System.AppDomain.CurrentDomain.add_ReflectionOnlyAssemblyResolve

There is an attempt to provide this resolution here: https://github.com/fsharp/FSharp.Data/blob/master/src/CommonProviderImplementation/AssemblyResolver.fs#L67. I'm not sure what's going wrong with it.

This resolution is to support your calls to ReflectionOnlyLoad in places like this: https://github.com/fsharp/FSharp.Data/blob/master/src/CommonProviderImplementation/AssemblyResolver.fs#L74

In general, if you are going to use ReflectionOnlyLoad in order to provide types, then yes, I you will need to manage binding redirects and loads of dependent assemblies like FSharp.Core yourself. You are already tryingn to do this, but there must be something going wrong with it.

Anyway, that's the core of the problem - it's not a missing binding redirect on devenv.exe.config nor a problem with the F# compiler/tools - it's just that using ReflectionOnlyLoad to provide types is non-trivial. If your F# assembly has a dependency on 4.3.0.0, you have to resolve that using the event above.

[ovatsus]

If you look a the history of that file I've been going back and forward between solutions, and nothing seems to work correctly in all cases. We're currently supporting:

• VS2012 compiling to FSharp.Core 4.3.0.0
• VS2012 compiling to FSharp.Core 2.3.5.0
• VS2013 compiling to FSharp.Core 4.3.0.0
• VS2013 compiling to FSharp.Core 4.3.1.0
• VS2013 compiling to FSharp.Core 2.3.5.0
• VS2013 compiling to FSharp.Core 2.3.6.0
• VS2013 compiling to FSharp.Core 3.3.1.0
• Mono F# 3.0 with FSharp.Core 4.3.0.0

Currently that all works, the only downside is that you have to have 4.3.0.0 in the gac, would be nice to remove that restriction, but we shouldn't penalize the rest.

Strangely enough, if we have FSharp.Data referencing a type from FSharp.Core 2.3.5.0, but we're really running in 2.3.6.0, there's no problem, but if we're using a type from FSharp.Core 4.3.0.0 but we're realling running in 4.3.1.0, there is a problem. Because of that, originally we only used ReflectionOnlyLoad for portable libraries, but when VS2013 came out we had to start using it for full .Net version also

I'd be glad if someone send a pull request that fixs this for all cases... My hair is becoming white trying to get this right...

That's an excellent list of code generation targets to support. I'll try to repro and see what's going wrong with the resolution.

[ovatsus]

Having two fsharp.data packages, one for F# 3.0 and another for F# 3.1 would be the ideal.

@ovatsus which scenarios require 4.3.0.0 in the GAC?