Distinguish publishing objectives
Record whether the goal is smaller downloads, faster startup, reduced diagnostic exposure or a particular deployment model. Trimming and Native AOT have supported scenarios and constraints; neither is a universal obfuscation switch. Select a target framework and runtime supported by the application and its dependencies.
Inventory reflection-based serialization, dependency injection, configuration-driven type lookup and plugin loading. Include dependencies even when your own code appears static. A library update can introduce a new dynamic pattern without changing the public API your application calls.
Make analysis warnings actionable
Enable appropriate analysis in the actual project and inspect the warning location, call chain and affected member requirements. Choose a fix that expresses the runtime contract or makes the code easier to analyze. Avoid suppressing every warning in a project file simply to obtain a clean build log.
Where reflection is necessary, document what members must remain available and why. Where a source-generated or explicit alternative fits the product, evaluate it with real application data. An annotation is a promise about behavior; it should not be added just because a search result suggests it clears an error.
Build an application-level test fixture
Publish a small representative consumer that exercises the library and its relevant dependencies. A library-only build may lack enough implementation information to expose all trimming issues. Include data and configuration that cause dynamic branches to execute, not only direct method calls that the compiler can already see.
Test deserialization of prior-release records, plugin discovery, platform integrations and the failure cases expected by customers. Run the actual published output on the target runtime or platform. Tests that execute an untrimmed development build do not establish that the trimmed artifact retains the required members.
Preserve diagnostics and signed integrity
Decide which PDBs and other resources stay private and how production failures are diagnosed. Reduced public metadata should not eliminate the ability to investigate a customer issue. For Native AOT, follow the current deployment guide for its additional compatibility constraints and target-specific diagnostic workflow.
Keep publishing, packaging and all intended transformations before the relevant signing step. Do not rename metadata or append a marker to a signed assembly or executable and assume its signature remains valid. Verify the final package and preserve a rollback artifact.
CloneGuard can provide bounded exposure screening and an exact receipt for supported outputs. It does not prove .NET trimming safety, rewrite IL, or establish Native AOT equivalence. Report resolved warnings, published-output tests and remaining unsupported patterns as separate evidence from a release inventory result.
Practical checklist
- Document deployment objective and dynamic features.
- Investigate warnings through their call chains.
- Test a published consumer with realistic data.
- Retain private diagnostics and validate final signing.
Sources and further reading
Primary references support the technical details. Procedures here are guidance; only explicitly recorded project results describe tests we ran.
Prepared with AI assistance. How this library is produced. Suggest a correction; keep private code and credentials out of public issues.