fsprojects / FSharp.TypeProviders.SDK

The SDK for creating F# type providers
https://fsprojects.github.io/FSharp.TypeProviders.SDK/
MIT License
298 stars 94 forks source link

VS2017 generates stackoverflow when installing a TypeProvider with Nuget. #292

Closed Thorium closed 5 years ago

Thorium commented 5 years ago

FSharp generates stackoverflow when installing a TypeProvider with Nuget. But I expect the problem is in providedtypes.fs and not in FSharp-compiler.

Detailed repro steps so we can see the same problem

  1. Open Visual Studio, select Visual F#, create a new Class Library (.NET Standard)
  2. Open Nuget package manager, type: Install-Package SQLProvider -Version 1.1.59
  3. Accept the license and see what happens.

Expected behaviour

I would expect the process to either success or crash in well-behaved manner.

Actual behaviour

Visual Studio 2017 performs stack overflow, and Microsoft Error reporting freezing the Visual Studio.

Known workarounds

If used with Paket or installed "manually" by editing the solution file, and then restored (e.g. with dotnet.exe), then it seems to work.

Related information

VS2017, Package Manager Console Host Version 4.9.3.5777 NuGet version: 4.6.2.5055 dotnet.exe --version : 2.1.504 VS version: 15.9.7 OS version: Microsoft Windows [Version 10.0.17134.590] Related: https://github.com/fsprojects/SQLProvider/issues/600

Thorium commented 5 years ago

This could help or maybe not: https://github.com/fsprojects/FSharp.TypeProviders.SDK/pull/183/commits/df543bd4498231ac96454586aefa84e361bc9abe

Edit: Did not help.

Thorium commented 5 years ago

How do I say to dotnet.exe that instead of the normal fsc.exe use this compiled debug-build from Visual FSharp repo and do verbose output? I expect it's still the net40 version that is called by Visual Studio, so C:\git\visualfsharp\Debug\net40\bin\fsc.exe

Thorium commented 5 years ago

The loop is inside ProvidedTypes.fs:

member __.TryBindType(nsp:string uoption, nm:string): Type option = calls .GetType which goes to override x.GetType (nm:string) = which then calls again x.TryBindType(USome nsp, nm2)

https://github.com/fsprojects/FSharp.TypeProviders.SDK/blob/8cc9f9f8ca9b934e1f9d37743bc792dccc91675c/src/ProvidedTypes.fs#L7979 https://github.com/fsprojects/FSharp.TypeProviders.SDK/blob/8cc9f9f8ca9b934e1f9d37743bc792dccc91675c/src/ProvidedTypes.fs#L7944

Thorium commented 5 years ago

I think this happens when netstandard.dll is included in the Nuget package (as instructed under "Nuget package layouts you should use" title), and there are external references that refer also that dll, it starts to loop resolving on very basic types like System.String

Thorium commented 5 years ago

If I add there a little check to providedTypes.fs like this: https://github.com/Thorium/FSharp.TypeProviders.StarterPack/commit/417e548710b545675bc651aa288bd0626afd1d3f then the stackoverflow on package restore goes away, but of course, then when I try to use the typeprovider it will throw a design time error:

The type provider 'FSharp.Data.Sql.SqlTypeProvider' reported an error:
The design-time type 'System.String' utilized by a type provider was not found in 
the tartget reference assembly set '[
tgt assembly netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51; 
tgt... --<cut a list of assemblies>--

so somehow these basic types should be also mapped to come from somewhere.

Thorium commented 5 years ago

Ok, chatted with Don in the fsharpx, it seems that the issue is referring two different netstandard.dll versions. Currently the working file should come from the deprecated Nuget package.