[DX] .NET unit tests fail to build locally without -p:SignAssembly=false (InternalsVisibleTo dropped under signing)

[NathanTarbert]

Summary

Running any .NET unit-test project directly — e.g. dotnet test tests/AGUI.Client.UnitTests — fails to compile locally with a wall of CS0122 '<type>' is inaccessible due to its protection level errors, even on a clean checkout of main. The tests only build when -p:SignAssembly=false is passed, which CI does but a developer running the obvious command does not.

Root cause

sdks/dotnet/Directory.Build.props sets:

<SignAssembly>true</SignAssembly>
<AssemblyOriginatorKeyFile>$(MSBuildThisFileDirectory)AGUI.snk</AssemblyOriginatorKeyFile>

Each library exposes internals to its test assembly via, e.g. src/AGUI.Client/AGUI.Client.csproj:

<ItemGroup Condition="'$(SignAssembly)' != 'true'">
  <InternalsVisibleTo Include="AGUI.Client.UnitTests" />
  <InternalsVisibleTo Include="AGUI.Hosting.AspNetCore.IntegrationTests" />
</ItemGroup>

Because the InternalsVisibleTo items are gated on '$(SignAssembly)' != 'true', a default local build (where SignAssembly=true) generates no InternalsVisibleTo attribute at all — so the test projects, which reference many internal types (ToolCallBuilder, TextMessageBuilder, AGUIHttpTransport, EventStreamConverter, …), fail to compile.

How CI avoids it

.github/workflows/unit-dotnet-sdk.yml runs every test project with -p:SignAssembly=false:

dotnet test tests/AGUI.Client.UnitTests -c Release -p:SignAssembly=false

So CI is green — this is purely a local-developer papercut. The failure mode (dozens of CS0122 errors) gives no hint that the fix is a build flag.

Impact

• dotnet test tests/<Project> — the natural command — fails on a clean tree.
• The CS0122 errors are confusing and point at unrelated test files, not at the signing config.
• New contributors (and coding agents) waste time diagnosing what looks like a broken checkout.

Suggested fixes (pick one)

1. Make InternalsVisibleTo work under strong-naming by including the public key (the SDK-native <InternalsVisibleTo> item appends $(PublicKey) automatically for signed assemblies — dropping the Condition may be enough), so the flag is never needed; or
2. Auto-disable signing for local/dev builds (e.g. only sign in Release/CI via a Directory.Build.props condition), so the default dotnet test works; or
3. If neither is desired, document the -p:SignAssembly=false requirement prominently in the .NET SDK README / contributing guide.

Environment

• Reproduced on a clean main checkout, .NET SDK 10.0.100, macOS.

[1aifanatic]

@ag-ui-protocol/copilotkit I've opened #2296 for this — happy to be assigned, or to trim the scope if you'd prefer.

@NathanTarbert your diagnosis was right, and I can confirm it independently: I hit the exact CS0122 wall running dotnet test tests/AGUI.Server.UnitTests on a clean main before I'd found this issue.

One wrinkle worth flagging on option 1: dropping the Condition alone isn't sufficient. Two things are broken, not one — the test assemblies also aren't signed (SignAssembly sits inside the '$(IsPackable)' == 'true' group), and a strong-named assembly can only grant InternalsVisibleTo to another strong-named assembly. So removing just the condition trades CS0122 for CS1726.

The other half of the guess was right though: the SDK does append PublicKey=$(PublicKey) to any InternalsVisibleTo item lacking explicit Key metadata — it just never derives $(PublicKey) from the .snk itself. Setting it explicitly (conditioned on SignAssembly) makes the default path work while leaving -p:SignAssembly=false behaving exactly as before.

Verified with no flag across net8.0/net9.0/net10.0: 474 unit tests × 3 TFMs plus 117 integration tests, all green, and the packable assemblies keep public key token d5950b1d09108385 after a clean rebuild.

I also dropped the flag from the two workflows, since with it CI was only ever testing the unsigned configuration — never the one that actually ships. Easy to revert that part if you'd rather keep the unsigned path covered.