.NET SDK

The .NET SDK is undergoing a deduplication process to reduce installation size and improve disk footprint. This initiative aims to eliminate redundant assemblies, which significantly reduces the size of the SDK in high-volume, ephemeral environments like containers and CI/CD pipelines.

Key benefits include:

• Reduced Network Costs: Smaller compressed archives lead to faster downloads.
• Reduced Time Costs: Smaller archives result in faster extraction times.
• Capacity for Growth: Deduplication provides the necessary headroom to accommodate larger features like Native AOT without significantly increasing the overall SDK footprint.

Version 0.2.0 of the .NET SDK containerization feature introduces the following capabilities:

• Registry Authentication: Support for authenticating to container registries.
• Visual Studio Integration: Support for publishing containers directly from within Visual Studio.
• Container Customization: Expanded methods for customizing the properties and structure of your generated containers.

The .NET SDK uses filesystem-level hard link deduplication to reduce the size of SDK distributions and Docker images. This approach was chosen over a 'Shared Assembly Location' model to avoid the complexity of modifying component loading logic, changing assembly resolution paths, or risking performance regressions in sensitive toolchain components like the compiler.

Key benefits for users:

• Smaller Downloads: Linux SDK archives are significantly smaller (e.g., ~56 MB reduction in .NET 11.0 Preview 4).
• Faster Docker Pulls: Reduced image size leads to faster deployment and lower bandwidth consumption.

To avoid the 'torn SDK' issue at design time, the SDK uses an implementation of IAnalyzerAssemblyRedirector to redirect analyzer DLL loading.

Redirection occurs only when both of the following conditions are met:

1. Path Match: The suffix of the assembly path being loaded matches a path defined in the VS deployment metadata.
2. Version Match: The major and minor components of the SDK version (extracted from the path) match the major and minor components of the version specified in the VS metadata.json.

If an analyzer cannot be matched via these rules, it will attempt to load from the SDK path. If that analyzer references a Roslyn version newer than the one in Visual Studio, it will fail to load.

The .NET SDK and Visual Studio are being decoupled to ensure consistent build experiences and independent design-time behavior. This prevents 'torn state' issues where a mismatch between the .NET SDK version and the Visual Studio version causes compatibility errors, such as analyzer assembly version mismatches.

Key Terminology

• msbuild: The .NET Framework-based MSBuild included with Visual Studio.
• dotnet build: The .NET Core-based MSBuild included with the .NET SDK.
• torn state: A condition where the .NET SDK and Visual Studio are not in sync (e.g., using a newer SDK than the installed Visual Studio version).
• .NET SDK project: A project using the .NET SDK project format.
• analyzers: Refers to both analyzers and source generators.

The Static Web Assets SDK creates a virtual file system that unifies static files from various sources: the project's wwwroot, ProjectReference libraries, NuGet packages, and the shared framework.

• During development: ASP.NET Core's static file middleware serves files through this virtual layer.
• At build time: SWA generates a manifest mapping virtual paths to physical disk locations.
• At publish time: SWA copies assets to their final output locations and produces endpoint manifests for runtime serving (handling routes, headers, and content negotiation).

Assets enter the SWA pipeline through five distinct source types:

• Discovered: Files located in the current project's wwwroot directory.
• Computed: Assets generated during the build process (e.g., scoped CSS bundles) via extension point targets.
• Project: Assets from referenced projects (ProjectReference). These are prefixed with the reference's BasePath (e.g., _content/{PackageId}).
• Package: Assets bundled within NuGet packages (.nupkg). These are imported via package manifests.
• Framework: Shared framework files (e.g., Blazor runtime JS). These are materialized into an intermediate directory ({IntermediateOutputPath}/fx/{SourceId}/) and treated as Discovered assets in the consuming project.

The test filtering framework follows a specific logic to determine if tests should run:

1. Is this a PR build?
   • No (CI): RunAlways=CI triggers; nothing is skipped, all tests run.
   • Yes (PR): Proceed to step 2.
2. Do changed files match any GlobalTriggerPaths?
   • Yes: Nothing is skipped, all tests run (this handles shared infrastructure like eng/Version.Details.xml).
   • No: Proceed to step 3.
3. For each scope:
   • Do changed files match any TriggerPaths?: The scope runs (not skipped).
   • No match: The scope is skipped, and its test projects are excluded from submission.