[Audit-Medium] orphaned generated .cs files survive source or metadat…

[pepone]

AI-generated audit finding — this issue was opened from an automated security/correctness audit. It has not been triaged by a human yet; verify the reasoning, reproducibility, and severity before acting on it.

Medium: orphaned generated .cs files survive source or metadata changes and can keep compiling — NEW

Affected code:

• src/IceRpc.Slice.Tools/IceRpc.Slice.Tools.props:49 — default output directory is $(MSBuildProjectDirectory)/generated
• src/IceRpc.Slice.Tools/IceRpc.Slice.Tools.targets:63 and src/IceRpc.Slice.Tools/IceRpc.Slice.Tools.targets:67 — current outputs are computed from the current SliceFile set only
• src/IceRpc.Slice.Tools/IceRpc.Slice.Tools.targets:72-99 — the build includes only the outputs for the current SliceFile items
• src/IceRpc.Slice.Tools/IceRpc.Slice.Tools.targets:102-103 — SlicecClean deletes only the outputs of the current SliceFile items

Verification:

Confirmed by inspection. The package has no mechanism to discover and remove previously generated outputs that are no longer represented by the current SliceFile item set.

This creates several concrete stale-output paths:

• a .slice file is deleted or removed from the project,
• a SliceFile changes OutputDir, leaving the old generated path behind,
• a SliceFile changes IceRpc from true to false, leaving the old .IceRpc.cs behind.

Because the default output directory is under the project root (generated), these stale .cs files continue to match the SDK's default C# include glob in ordinary SDK-style projects. That means the build can continue compiling types generated from a Slice file that no longer exists or from an IceRPC generator pass that has been disabled.

Impact:

• Build drift: removed or reconfigured Slice inputs can leave ghost generated code in the compilation.
• Confusing failures or false success after schema cleanup, renames, or metadata changes.

Recommendation:

• Track generated outputs with a manifest or stamp file and remove obsolete outputs before or during Slicec.
• At minimum, extend SlicecClean to delete previously recorded outputs, not just outputs computed from the current SliceFile items.
• Add an integration test that builds once, removes or reconfigures a .slice file, rebuilds, and verifies that stale generated files are not still compiled.

Status: Valid, Medium severity.

---

Source report: src-IceRpc.Slice.Tools-audit-2026-04-14.md (finding orphaned generated .cs files survive source or metadata changes and can keep compiling — **NEW**)

Severity (auditor-assigned): Medium

[pepone]

How Protobuf/gRPC handles this

Grpc.Tools generates into obj/ (IntermediateOutputPath) rather than a source-visible directory. It uses .protodep manifest files to track generated outputs and has a _Protobuf_Clean_AfterCsClean MSBuild target that removes stale outputs during dotnet clean. Because obj/ is excluded from source control and fully rebuilt on clean, orphaned files don't affect the build.

Current IceRPC Slice Tools design

The Slice tools generate into a generated/ directory under the project root. This was chosen for two reasons:

1. Auto-include: generated .cs files are automatically picked up by the SDK's default compile glob.
2. IDE visibility: files appear in Visual Studio's Solution Explorer for inspection and navigation.

Trade-offs and considerations

Looking at this more carefully, neither reason is a strong blocker for switching to obj/:

• Auto-include is not a significant advantage — the SliceCompile target already needs to handle adding compile items for files that don't previously exist (e.g., on a clean build). So the MSBuild integration for obj/-based outputs would be similar in complexity.
• IDE visibility / navigate to definition should still work with generated files in obj/. The C# compiler and IDE tooling support navigating to generated source regardless of where it lives on disk.

Generating into obj/ would eliminate the orphaned file problem entirely (since obj/ is always cleaned and rebuilt), and it would align with the established Protobuf precedent in the .NET ecosystem.

Given that we're still in early 0.x releases before 1.0, there's room to consider this design change. Worth evaluating before we commit to the current layout for 1.0.

[pepone]

One clarification: adding a manifest to track generated outputs is orthogonal to where we put the generated code. A manifest would improve clean and rebuild regardless of output directory — SlicecClean could delete all previously recorded outputs (not just those computed from the current SliceFile set), and rebuild could detect orphans before regenerating. This is worth considering independently of any output directory change.