F# Type Provider compile-time generation and runtime assembly requirement diagnosis

Direct Answer

There is no universal metadata or compiler attribute that declares whether a type provider needs its assembly at runtime. The requirement is provider-specific and must be determined from the provider's documentation, source code, or by inspecting the generated IL. The F# compiler does not emit a standard flag; it simply embeds references to the provider assembly in the generated types when the provider's design-time code uses types from its own implementation assembly.

Likely Explanation

Most type providers fall into two categories:

• Runtime-dependent: The generated code calls back into the provider assembly (e.g., to fetch schema data, execute dynamic queries, or access provider-defined base classes). Removing the provider assembly causes FileNotFoundException or TypeInitializationException on first use.
• Compile-time-only: The provider emits fully self-contained types (e.g., plain records or classes with no external dependencies). The provider assembly can be omitted from the output.

NuGet packages often ship a separate runtime assembly (e.g., Provider.Runtime.dll) that must be present even if the design-time assembly is not. The design-time assembly is loaded by the compiler process; the runtime assembly is loaded by the application.

Confirmed Behaviors

• The F# compiler loads the provider assembly during compilation (design-time) and emits IL that references it.
• The .NET SDK copies referenced assemblies to the output directory based on project settings (PrivateAssets, CopyLocal, framework references).
• If the provider assembly is marked PrivateAssets=all or is a transitive dependency without a direct project reference, it may not be copied, leading to runtime failures.
• Mismatched target frameworks between the provider and the host project can cause BadImageFormatException.

Diagnostic Steps

1. Consult the provider's documentation for explicit runtime requirements. Look for phrases like "requires provider assembly at runtime" or "runtime assembly".
2. Inspect generated code with a decompiler (ILSpy, dotPeek) to see if emitted types reference the provider assembly.
3. Build and verify output: ensure the provider DLL (and any separate runtime DLL) appears in the build output directory. Add a direct PackageReference with PrivateAssets=all removed or set CopyLocal=true if missing.
4. Run the application and capture the exact exception. A FileNotFoundException naming the provider assembly confirms a runtime dependency.
5. Check project file for PrivateAssets=all on the provider package or FrameworkReference that might suppress copying.

Compiler and SDK Factors

• F# compiler: Resolves the provider assembly via the reference graph at compile time. The generated IL contains assembly references to the provider's implementation types.
• .NET SDK: Controls which assemblies are copied to the output directory. PrivateAssets=all prevents transitive copying; CopyLocal on a direct reference forces it.
• Design-time parameters (connection strings, file paths) must be resolvable in the build environment. The compiler does not validate their runtime availability.

One Missing Detail

Which specific type provider (name and version) are you using? Behavior varies widely (e.g., SQLProvider, FSharp.Data, SwaggerProvider), and the exact requirement can only be confirmed for that provider.