Microsoft .NET is a development platform rather than one desktop application. Its runtime executes compiled applications, while its SDK contains the command-line interface and a compiler-led build toolchain. Libraries and application stacks add the APIs for web or Windows desktop projects. Installing only a runtime can make an existing app run, but it does not add the SDK commands needed to create or compile a project.
The command can restore packages before it builds
The dotnet driver runs project commands and starts framework-dependent application DLLs. dotnet new creates project files from a template. Build compiles a project and its dependencies, test builds and runs the configured tests, pack creates a NuGet package, and publish writes deployable output.
Several Microsoft .NET project commands run restore implicitly when the project needs it. Restore reads package references, resolves them through NuGet sources and fills the local package cache. A command that appears to perform only a build or test can therefore contact a package feed before compilation begins. A private feed may require credentials, and signed-package verification depends on a suitable certificate root.
An automated build can run restore as an explicit step and pass --no-restore to later commands. That arrangement controls when package resolution and network access occur. It does not remove the declared dependencies from the project.
Framework-dependent and self-contained outputs assign different work
A framework-dependent publication contains the app and its dependencies but relies on a compatible shared runtime on the destination machine. An executable host can start it directly, while its portable DLL can run through the dotnet command.
A self-contained Microsoft .NET publication carries its selected runtime. It targets one operating system and processor architecture and produces a larger output. Patching the shared Microsoft .NET runtime on the machine does not replace the runtime bundled with that app. The publisher must rebuild and redeploy the self-contained output to move it to the patched runtime.
Single-file publication bundles application-dependent files into one binary, but the result remains specific to its target system and architecture. Some bundled content can still extract before startup. One visible file therefore does not create one universal build for every machine.
global.json selects the SDK rather than the target runtime
Within Microsoft .NET, a global.json file tells the CLI and build resolver which installed SDK to select. Without it, the CLI chooses the highest installed SDK. The SDK value needs a full version; the field does not accept a wildcard or range. A roll-forward policy controls whether another installed SDK can satisfy the request.
The CLI searches upward from the current working directory for global.json, while the MSBuild resolver starts from the solution or project directory. Running the same repository from another directory can therefore discover a different file. A strict selection also fails when the requested SDK is absent. dotnet --list-sdks and dotnet --list-runtimes show the two installed sets separately.
Trimming and Native AOT impose different limits
Trimming removes code that static analysis regards as unused. Reflection and other dynamic access patterns can hide a required path from that analysis, so trimming warnings can require source annotations or code changes. A successful compile does not prove that every trimmed runtime path remains reachable.
Native AOT compiles a self-contained native executable without JIT compilation at run time. It does not support runtime code generation or dynamic assembly loading. Libraries used by that output must also work with trimming and ahead-of-time compilation. The build requires a native toolchain for the target platform.
