Tricky to reference .NET Standard 2.0 components from F# Interactive

[dsyme]

Referencing a .NET Standard 2.0 component from F# Interactive (fsi.exe) fails with

"netstandard.dll 2.0.0.0" is not part of the fsi.exe application or an error such as 

or

unknown(1,1): error FS3216: type 'Microsoft.EntityFrameworkCore.Design.AnnotationCodeGeneratorDependencies' not found in assembly 'Microsoft.EntityFrameworkCore.Relational, Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. A possible cause may be a version incompatibility. You may need to explicitly reference the correct version of this assembly to allow all referenced components to use the correct version.

Repro steps

Provide the steps required to reproduce the problem

1. Create a .NET Standard 2.0 component

   dotnet new classlib -o -lang F# lib2
   cd lib2
   add code file:
       module Say 
       let hello (t:System.DateTime) = printfn "the time is %A" t
   
   dotnet restore
   dotnet build
   

2. Reference this from .NET Framework fsi.exe

Release\net40\bin\fsi.exe -r ..\misc\lib2\tplib1.dll
> Say.hello System.DateTime.Now;;

Expected behavior

Works ok and prints the current time

Actual behavior

stdin(1,1): error FS0074: The type referenced through 'System.DateTime' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard'.

Known workarounds

1. Manually acquire the package NETStandard.Library.NETFramework

2. Add an explicit reference to packages\NETStandard.Library.NETFramework.2.0.0-preview2-25405-01\build\net461\lib\netstandard.dll e.g.

#r @"C:\GitHub\dsyme\visualfsharp\packages\NETStandard.Library.NETFramework.2.0.0-preview2-25405-01\build\net461\lib\netstandard.dll"

Related information

master, Windows, .NET Framework 4.7 or 4.6.1

[terrajobst]

The best way to get the correct set is to configure the fsi application to include all .NET Standard 2.0 components necessary for .NET Framework 4.6.1 and up. This can be done by setting this property:

<Project>
  <!-- ... -->
  <PropertyGroup>
    <DependsOnNETStandard>true</DependsOnNETStandard>
  </PropertyGroup>
  <!-- ... -->
</Project>

[dsyme]

@cartermp @KevinRansom Given @terrajobst's advice I'd like guidance on this at some point (no huge rush). It seems that including the facade DLLs as part of the compiler seems to be the correct advice, though I think the real concern is auto-referencing them as part of the F# Interactive scripting model.

I understand the reluctance to do this. Perhaps adding just netstandard.dll is sufficient since most other facade DLLs are part of .NET 4.6.1

Anyway, I added a description of the workaround, which is to manually acquire NETStandard.Library.NETFramework and add an explicit reference to the facade DLLs you need:

#r @"packages\NETStandard.Library.NETFramework.2.0.0-preview2-25405-01\build\net461\lib\netstandard.dll"

Not pretty but it works

[terrajobst]

though I think the real concern is auto-referencing them as part of the F# Interactive scripting model.

Why would you need to auto-reference them? Presumably F# interfactive is using RefEmit to run code within the current process. The CLR should be able to load the appropriate assemblies on-demand from the fsi directory, no?

I understand the reluctance to do this. Perhaps adding just netstandard.dll is sufficient since most other facade DLLs are part of .NET 4.6.1

True, but customers loading pre-.NET Standard 2.0 components will get pretty bad/unactionable error messages (assembly load errors, type load errors, missing member errors).

[dsyme]

Why would you need to auto-reference them?

In the F# compilation stages being run in F# Interactive prior to RefEmit we need to follow the type forwarders to emit correct code (to understand that [netstandard]System.Int32 --> [mscorlib]System.Int32 etc.), to determine type equality etc.

True, but customers loading pre-.NET Standard 2.0 components will get pretty bad/unactionable error messages (assembly load errors, type load errors, missing member errors).

I agree this is technically possible, which is why I included the whole lot in my currently doomed PR. My estimate is that this doesn't actually happen much yet, for two reasons

1. For .NET Standard 1.x components there is often a .NET Framework version in the package - or portable versions. This is what people reference if it is there. Basically most F# scripters probably aren't referencing any .NET Standard 1.x components at all.

   I think it will be much more common for nuget packages to only have .NET Standard 2.0 components - because a .NET Standard 2.0 is often completely adequate replacement for the .NET Framework version.

2. Versions (e.g. 4.0.0.0) of some assemblies like System.IO are shipped in the implementation assemblies of .NET Framework 4.6.1. F# Interactive will happily resolve to these implementation assemblies as a last resort even if System.IO 4.1.2.0 was requested in a reference and regardless of version. While this is not "sound", I suspect the forwarders in these implementation assemblies are adequate for most .NET Standard 1.x components

[terrajobst]

Strike what I said earlier; I was only thinking of runtime. In order to compile the F# code to IL you of course need to load the facades. This is proof I'm not nearly as smart as many people believe (and most don't even think that highly of me to begin with 😏 )