C# 8.0 NRT boundary handling for legacy libraries without nullable annotations

Answer to the Exact Questions

1. Is there a documented way to locally override the oblivious treatment for a specific NuGet package reference without disabling NRT project-wide?

No. The C# 8.0 compiler has no per-assembly setting that changes how it interprets an external reference lacking [Nullable] attributes. The compiler treats any assembly without these attributes as oblivious, assuming all reference types are nullable, and this behavior applies globally within the project's compilation context.

2. Does the compiler provide any configuration or analyzer option to treat unannotated external assemblies as if they were fully annotated with [Nullable] attributes?

There is no built-in compiler flag or analyzer that can make the compiler assume full annotations for a legacy assembly. The only ways to influence the compiler's view are to modify the assembly itself or to wrap calls from annotated code.

Confirmed Facts

• The compiler's treatment of an external assembly is determined by the presence of [Nullable] attributes emitted by that assembly.
• Adding [assembly: Nullable] or annotating individual types/members in the legacy assembly makes the compiler treat it as fully annotated.
• When you cannot modify the assembly, the recommended mitigation is to isolate the boundary with #nullable restore / #nullable disable and use the null-forgiving operator (!) where appropriate.

Practical Steps for Your Scenario

1. Verify the legacy NuGet package's metadata:

   dotnet list package --include-transitive

   This confirms whether the package emits [Nullable] attributes. If it does, you can safely enable NRT project-wide.
2. If the package is oblivious and you control its source:
   • Add [assembly: Nullable] at the top of a new source file in the project and recompile the library.
   • Alternatively, annotate each public type or member with string?, Person?, etc., to provide explicit nullability information.
3. If you cannot modify the library:
   • Wrap all calls to the legacy API in a small adapter assembly that you write. Annotate the adapter's public surface with the correct nullability, then reference that adapter from your annotated code.
   • Or, surround the call site with #nullable restore and #nullable disable to silence the compiler about the oblivious boundary, and use the null-forgiving operator where you are confident the value will not be null.
4. After making changes, run the compiler with /warnaserror to ensure that no CS8600-CS8604 warnings are emitted when calling into the modified assembly:

   dotnet build -warnaserror

When to Ask for More Information

If you are unsure whether you have permission to modify the legacy assembly or whether IL weaving is acceptable under the library's license, please confirm that detail before proceeding. The choice of mitigation strategy depends on that constraint.

Key Takeaway

In C# 8.0 there is no per-assembly override to treat an unannotated library as fully annotated. The only viable approaches are to modify the library to emit [Nullable] attributes or to isolate the boundary with #nullable directives and the null-forgiving operator.