Is authoring TP in .NET 8 unsupported?

cannorin commented 5 days ago

Description

We F#+ team are trying to migrate our entire codebase to F# 8 and net8, dropping older framework versions including net45 and even netstandard2.0. However, our type provider project seemingly produces an invalid assembly once we switch it to net8.

The TP project compiles just fine, but the consuming project fails to compile with the following error:

FSC : warning FS3005: Referenced assembly '.../src/obj/Debug/net8.0/ref/FSharpPlus.Providers.dll' has assembly level attribute 'Microsoft.FSharp.Core.CompilerServices.TypeProviderAssemblyAttribute' but no public type provider classes were found

Is this a known limitation on authoring type providers in net8 or is this rather an unexpected issue?

Repro steps

We have created a small project that reproduces the above error.

We used the type provider template from FSharp.TypeProviders.Templates, merged the runtime and design time projects to make it resemble our setup, and upgraded everything to use F# 8 and net8.

https://github.com/cannorin/net8-typeprovider-fail-repro/tree/simple

Here is the actual error message from a CI log: https://github.com/cannorin/net8-typeprovider-fail-repro/actions/runs/9658205746/job/26638915041

Expected behavior

TP projects built in net8 must be consumable.

Actual behavior

The consuming project fails to compile with the above error.

Known workarounds

Keep using netstandard2.0.

@vzarytovskii Disabling refassemblies actually makes the project compile and the tests run successfully. Thank you! As you have mentioned, however, Ionide-VSCode (and thus FSAC) seems to hang when trying to typecheck the test project. So my conclusion is that net8 TP projects are effectively unconsumable at the moment, and it is a known limitation.

vzarytovskii commented 3 days ago

@baronfel might actually know better what's happening in ionide. Technically compiler doesn't care much which target tp is, it's just if it's design time, tooling needs to be able to load that target.

baronfel commented 3 days ago

I don't immediately know what happens in Ionide here - we don't have any tests covering TP usage directly nor do we do any explicit customization of the compiler around them so it should be 'vanilla' out of the box behavior.

Thorium commented 12 hours ago

Just general notes and questions (as TP structure is not very well documented):

The TypeProviderAssemblyAttribute has to be publicly visible. Is it, if it's inside modules? Or should the Repro.DesignTime.fs module ReproImplementation be namespace ReproImplementation ?
TypeProviderAssemblyAttribute is needed only runtime. As you link the file containing that to both projects, you may want to add a directive to not include that in design-time just for easier debugging.
Does that need ".dll" to the end?

#if !IS_DESIGNTIME
// Put the TypeProviderAssemblyAttribute in the runtime DLL, pointing to the design-time DLL
[<assembly:CompilerServices.TypeProviderAssembly("Repro.DesignTime.dll")>]
do ()
#endif

Is there some kind of naming conventions for fsproj properties like <Name>Repro</Name> or assembly attributes like [<assembly: AssemblyTitleAttribute("Repro")>] that is used to decide the linking?
As far as I understand the project reference is not needed, it's just for ensure that the desgin-time dll is actually done building before the runtime executes. So you could do it also e.g. something like this in Repro.Runtime.fsproj without a project reference:
```
<Target Name="BeforeBuild">
  <MSBuild Projects="..\Repro.DesignTime\Repro.DesignTime.fsproj" Targets="Build" Properties="Configuration=$(Configuration);TargetFramework=net8.0" />
</Target>
```

As Vlad pointed above, to run VS2022 intellisense you need NetStandard 2.0, so your .NET8-only TP would work only with dotnet.exe and VS Code.

fsprojects / FSharp.TypeProviders.SDK