Example TypeProvider is not created properly

[PawelStadnicki]

Description

I'm trying to create sample TypeProvider (Lemonade) as described: https://fsprojects.github.io/FSharp.TypeProviders.SDK/ While generating nuget I'm receiving following warnings (from paket template):

The first thing to correct is to change netstandard from 2.0 to 2.1 (both project references 2.1) The second issue is that typeproviders doesn't exist after build , hence the warning.

It worked when the last time I wanted to build this provider (~6 months ago), I can see that there is a couple of new things since then like runtime project

so it may have impact it is not created (but I have no idea how)

The last thing is that my dependencies (FSharp.Data and Thoth.Json.Net) added after are not included in the nuget package. But it may be causes by the first issues as well.

Repro steps

Lemonade Provider created according to steps from https://fsprojects.github.io/FSharp.TypeProviders.SDK/

Expected behavior

Provider is build without workings and workarounds

Actual behavior

Warning that typeproviders folder doesn't exists

Known workarounds

change the paket.template to use bin/Release/netstandard2.1/*.dll and build typeprovider fsharp41 folder manually with expected libraries

Related information

• Windows 10 PRO
• Visual Studio 2022

[mattnewport]

I ran into this problem as well. I was trying to get the type provider working in Visual Studio 2022 so I don't think netstandard2.1 is the right target as it doesn't work with .NET Framework? Anyway, I was able to get the example to work in Visual Studio by changing the target to netframework2.0 everywhere and then copying the .DesignTime.dll into a folder src/.Runtime/bin/Release/typeproviders/fsharp41/netstandard2.0 before running the dotnet paket pack nuget command.

It would be great if the examples were fixed to work out the box with Visual Studio 2022 as well as working for other hosts like Ionide.

[PawelStadnicki]

Hi Matt, I'm also working with it by copying dlls manualny, I have a lot of dependencies but that is not a big burden. It works for me with .net standard 2.1 as well.

wt., 1 mar 2022, 4:46 PM użytkownik Matt Newport @.***> napisał:

I ran into this problem as well. I was trying to get the type provider working in Visual Studio 2022 so I don't think netstandard2.1 is the right target as it doesn't work with .NET Framework? Anyway, I was able to get the example to work in Visual Studio by changing the target to netframework2.0 everywhere and then copying the .DesignTime.dll into a folder src/.Runtime/bin/Release/typeproviders/fsharp41/netstandard2.0 before running the dotnet paket pack nuget command.

It would be great if the examples were fixed to work out the box with Visual Studio 2022 as well as working for other hosts like Ionide.

— Reply to this email directly, view it on GitHub https://github.com/fsprojects/FSharp.TypeProviders.SDK/issues/382#issuecomment-1055581245, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANLT6BXKM3ZCCTWOZUG6LFLU5Y3VHANCNFSM5PAWK77Q . You are receiving this because you authored the thread.Message ID: @.***>

[cartermp]

netstandard2.1 would be the wrong target, yes. That would not allow the type provider to load in Visual Studio. It needs to be netstandard2.0 or netframework.

It worked when the last time I wanted to build this provider (~6 months ago), I can see that there is a couple of new things since then like runtime project

The changes you're seeing have been in place much longer than that. The F# compiler contains the necessary targets to move dlls around. My suspicion is there's a difference in the compiler shipped with VS 2022/.NET 6 that's causing this issue.

@KevinRansom and @dsyme any thoughts?

[PawelStadnicki]

I'm using Type Provider only in the context of .NET Interactive/ Visual Studio Code, that is why netstandard2.1 is fine for me

[abelbraaksma]

It's not just netstandard2.1. Using the instructions with the Lemonade provider will create a project that fixes the FSharp.Core reference to 4.7. Trying to remove this reference (which is now implicit) fails, because Paket forcibly adds:

<DisableImplicitFSharpCoreReference>true</DisableImplicitFSharpCoreReference>

Still, even when overriding this to false in the generated fsproj files, lead to warnings by Paket that FSharp.Core was not referenced.

I just wanted to create the providers for Net6.0, so I figured, just change the target framework to this:

<TargetFramework>net6.0</TargetFramework>

but this subsequently lead to errors like:

error NETSDK1045: The current .NET SDK does not support targeting .NET 6.0. Either target .NET 5.0 or lower, or use a version of the .NET SDK that supports .NET 6.0.

Using net5.0 instead works. Not sure where this is blocked, as my daily work is writing net6.0 applications.

I'm probably going back to writing the type provider by hand and referencing the files by hand and probably just using nuget normally and not Paket. Not sure how to fix this, it's all just a little bit too magical.

Just to note, this was after:

dotnet new -i FSharp.TypeProviders.Templates
dotnet new typeprovider -n FSharp.MyTypeProvider -lang F#

[dsyme]

Remaining issues covered by #387