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

Question about intellisense being broken with .<Note> #390

Closed Thorium closed 1 year ago

Thorium commented 1 year ago

This is a bit long shot, but do you know why a TypeProvider intellisense is broken after Visual Studio 2022 version upgrade to 17.3.x?

image

It wants some reference to Windows 255.255.255.255, what is that dll, never heard? Which NuGet package is that from?

Or could this be a problem with Task type handling in ProvidedTypes.fs?

dsyme commented 1 year ago

@Thorium Please list a full repro - which type provider, what dependencies it has and so on

Thorium commented 1 year ago

I thought it would be nice to know if other people have similar problems and in which conditions. Google search doesn't expose a lot.

This was .NET Framework full, loaded SQLProvider (SSDT, no real database connection, just flat file parsing). I have also loaded FSharp.Data (with a few non-small xmls) and as far as I know, either of those are not having Nuget package references on .NET full (except maybe to FSharp.Core) or any referencing to a "Windows" anything.

The intellisense did work on VS2019 very well (maybe survivorship bias on my memories), but VS2022 it sometimes does, sometimes not. I don't know if this is related: image

That's why my initial suspects were:

Compile time the code works, and runs, it's just intellisense that is broken.

Thorium commented 1 year ago

One thing that might be related: I was running VS on Windows 10 in non-admin mode. As typically every VS update resets the short-cut back to non-admin permissions.

VS seems to use fsc things from C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\CommonExtensions\Microsoft\FSharp\Tools where dotnet.exe uses C:\Program Files\dotnet\sdk\7.0.100\FSharp

Thorium commented 1 year ago

Ok I think the intellisense being broken is not actually TypeProvider-issue as such, but this: https://github.com/dotnet/fsharp/issues/9206

Except type-providers can probe runtime assemblies, e.g. addDefaultProbingLocation-parameter in ProvidedTypes.fs and other Assembly.Load things.

Definitely I got the whole compiler to crash to this error (not only intellisense), when I tried to use a C# library returning me a ValueTask

Thorium commented 1 year ago

I think I found the issue. The TypeProvider had a reference to System.Net.Http which has dependency to System.Runtime.WindowsRuntime which is the poisonous dll referred also above. Some old WinRT stuff I suppose.

Causing that to load on the design-time dll (as reflection loads dependencies), somehow conflicted with something, causing this error. The solution, that seems to work so far, was to restrict the System.Net.Http reference target frameworks, as it has that dependency only on one of the target frameworks it has: https://www.nuget.org/packages/System.Net.Http#dependencies-body-tab

It's only needed in ".NET Core 5.0" which is a deprecated alias for UAP10.0. So restricting dependencies targetframeworks to exclude that, fixed the problem.