abelbraaksma
commented
2 years ago I found a workaround to get this to work in VS. Just use the template and then copy all the fs and fsi files over to a new .NET 6 project in Visual Studio. This ditches Paket, which seems to be at the root of this problem (I don't know enough about Paket, but it appears that it just doesn't work well with the new implicit F# library and upgrading to .NET 6, and/or upgrading the SDK version. Even after doing all that by hand, it still keeps giving warnings or errors and I didn't manage to sort NUnit issues at all, after upgrade no tests were found anymore).
The other takeaway here is that I think the design of the sln file containing the test project for the type provider is probably not a good idea, as that forces the type provider dll to be in use, which ruins the build. In fact, the Docs say so much: test the type provider in a different script or VS instance.
If you also face this, ensure that you link the source Runtime fs file in the Design project, above your DesignTime.fs and that you add the IS_DESIGNTIME compiletime constant to your project settings. The files ProvidedType.fsi/fs can either be linked or copied.
Finally, ProvidedTypes.fs contains a compile error on line 10840, which only shows if your run Fantomas (which tries to format this, but can't) or specify DEBUG_INFO:
#if DEBUG_INFO
member codebuf.EmitSeqPoint cenv (m:ILSourceMarker) = () // unit should not be here
if cenv.generatePdb then
....Another, less intrusive error is on line 10272, which is a "catch all" match, but the match already is exhaustive on the DU. You can just delete that line:
| _ -> failwith "EmitType"
dsyme
Description
Following the instructions here: https://fsprojects.github.io/FSharp.TypeProviders.SDK/, a bunch of things go wrong:
NUnit.Extension.TeamCityEventListener1.0.8 which was unlistedThe good news is that, besides all these issues, using
dotnet buildordotnet test, the project does successfully compile and the tests pass.Repro steps
Do as in the instructions, in an empty directory run:
These commands to start:
dotnet new -i FSharp.TypeProviders.Templates dotnet new typeprovider -n LemonadeProvider -lang F#
Then update Paket and compile:
cd LemonadeProvider dotnet tool restore dotnet paket update dotnet build -c release
Expected behavior
No warnings and an idiomatic F# project that can be opened and edited in Visual Studio. After all, it creates a
slnfile.Actual behavior
The first warnings are from Paket:
Next is, after opening the
slnfile in VS 2022, after opening a file fromMyTypeProvider.Runtime, I get these errors:And:
Finally, trying to build it in Visual Studio (which should, logically, be similar to
dotnet build), fails with these messages:Known workarounds
Not sure. Maybe using VS Code instead, or Rider. Haven't tried that yet.
For getting rid of the old version of FSharp.Core, this turned out to be not so easy, as the
Paket.Restore.targetscomes with the following lines:Setting these to false only gets them overridden. I did try to override them in the
fsprojfiles, and remove theFSharp.Corereferences in Paket, which seems to do the trick. But after this it still won't compile.I also wanted to build in
net6.0but that seemed to be utterly impossible and I wasn't sure what was blocking this, just too many spurious errors.Looks like quite a few of these errors are due to Paket not dealing well with Nuget packages, as explained here: https://github.com/fsprojects/Paket/issues/3064. For instance, trying to reference
NUnit3TestAdapterafter updating tonet6.0ornet5.0, this didn't work anymore and I received the following error:Changing
netstandard2.1tonetstandard2.0seemed to get rid of some errors and for some reason lets me occasionally compile in VS, but then, after I open thefsfiles themselves, it's mayhem again with red squigglies.Related information
This is probably also related to this Paket issue that still doesn't seem to be able to deal with the implicit FSharp.Core reference: https://github.com/fsprojects/Paket/issues/3972