fsharp-csharp-interop

F# And C# Interop

Purpose

Keep mixed F# and C# solutions intentional.

The practical job is to decide which language owns which responsibility, make the project-reference direction explicit, and shape public APIs so each language can call the other without awkward translation code leaking everywhere.

When To Use

• Use this skill when a solution contains both .fsproj and .csproj projects.
• Use this skill when adding an F# library to a C# app or service.
• Use this skill when adding a C# host or infrastructure project around F# domain code.
• Use this skill when public package APIs need to work well from both F# and C#.

Source Check

Use repo-local .NET files, checked-out dependency sources, Dash MCP or Dash HTTP for installed .NET docsets, and then official Microsoft documentation when Dash/local coverage is missing or stale:

• F# documentation
• C# documentation
• .NET CLI documentation
• dotnet add reference documentation

Boundary Workflow

1. Inspect project graph:

   rg --files -g '*.fsproj' -g '*.csproj' -g '*.sln' -g '*.slnx'
   

2. Identify the language-owned responsibilities:
   • F# domain library
   • C# host app
   • C# ASP.NET Core service
   • F# CLI
   • shared abstractions
   • tests
3. Choose dependency direction.
4. Shape the API at the boundary.
5. Add tests from the consuming side when the boundary is public or fragile.
6. Run solution-level build and tests.

Good Mixed Shapes

Common durable shapes:

• F# domain library consumed by a C# app or ASP.NET Core host
• F# transformation package consumed by C# tools
• C# infrastructure adapter consumed by an F# application
• shared test projects that verify public package behavior from both languages

Avoid mixed language solutions when the only reason is indecision. Ask for a language choice instead.