Dotnet deployment models

 Applications you create with .NET can be published in two different modes, and the mode affects how a user runs your app.

Publishing your app as self-contained produces an application that includes the .NET runtime and libraries, and your application and its dependencies. Users of the application can run it on a machine that doesn't have the .NET runtime installed.

Publishing your app as framework-dependent produces an application that includes only your application itself and its dependencies. Users of the application have to separately install the .NET runtime.

Both publishing modes produce a platform-specific executable by default. Framework-dependent applications can be created without an executable, and these applications are cross-platform.

When an executable is produced, you can specify the target platform with a runtime identifier (RID). For more information about RIDs, see .NET RID Catalog.

Platform-specific and framework-dependent

You can publish a framework-dependent app that's platform-specific by passing the -r <RID> parameters to the dotnet publish command. Publishing in this way is the same as publish framework-dependent, except that platform-specific dependencies are handled differently. If the app uses a NuGet package that has platform-specific implementations, only the targeted platform's dependencies are copied. These dependencies are copied directly to the publish folder.

While technically the binary produced is cross-platform, by targeting a specific platform, your app isn't guaranteed to run cross-platform. You can run dotnet <filename.dll>, but the app may crash when it tries to access platform-specific dependencies that are missing.

For more information about RIDs, see .NET RID Catalog.

Advantages

• Small deployment
  Only your app and its dependencies are distributed. The .NET runtime and libraries are installed by the user and all apps share the runtime.

• Cross-platform
  Your app and any .NET-based library runs on other operating systems. You don't need to define a target platform for your app. For information about the .NET file format, see .NET Assembly File Format.

• Uses the latest patched runtime
  The app uses the latest runtime (within the targeted major-minor family of .NET) installed on the target system. This means your app automatically uses the latest patched version of the .NET runtime. This default behavior can be overridden. For more information, see framework-dependent apps roll forward.

Disadvantages

• Requires pre-installing the runtime
  Your app can run only if the version of .NET your app targets is already installed on the host system. You can configure roll-forward behavior for the app to either require a specific version of .NET or allow a newer version of .NET. For more information, see framework-dependent apps roll forward.

• .NET may change
  It's possible for the .NET runtime and libraries to be updated on the machine where the app is run. In rare cases, this may change the behavior of your app if you use the .NET libraries, which most apps do. You can configure how your app uses newer versions of .NET. For more information, see framework-dependent apps roll forward.

Publish self-contained

Publishing your app as self-contained produces a platform-specific executable. The output publishing folder contains all components of the app, including the .NET libraries and target runtime. The app is isolated from other .NET apps and doesn't use a locally installed shared runtime. The user of your app isn't required to download and install .NET.

You can publish a self-contained app by passing the --self-contained parameter to the dotnet publish command. The executable binary is produced for the specified target platform. For example, if you have an app named word_reader, and you publish a self-contained executable for Windows, a word_reader.exe file is created. Publishing for Linux or macOS, a word_reader file is created. The target platform and architecture is specified with the -r <RID> parameter for the dotnet publish command. For more information about RIDs, see .NET RID Catalog.

If the app has platform-specific dependencies, such as a NuGet package containing platform-specific dependencies, these are copied to the publish folder along with the app.

Advantages

• Control .NET version
  You control which version of .NET is deployed with your app.

• Platform-specific targeting
  Because you have to publish your app for each platform, you know where your app will run. If .NET introduces a new platform, users can't run your app on that platform until you release a version targeting that platform. You can test your app for compatibility problems before your users run your app on the new platform.

Disadvantages

• Larger deployments
  Because your app includes the .NET runtime and all of your app dependencies, the download size and hard drive space required is greater than a framework-dependent version.

• Harder to update the .NET version 

        .NET Runtime (distributed with your app) can only be upgraded by releasing a new                     version of your app.

ReadyToRun Compilation 

.NET application startup time and latency can be improved by compiling your application assemblies as ReadyToRun (R2R) format. R2R is a form of ahead-of-time (AOT) compilation.

R2R binaries improve startup performance by reducing the amount of work the just-in-time (JIT) compiler needs to do as your application loads. The binaries contain similar native code compared to what the JIT would produce. However, R2R binaries are larger because they contain both intermediate language (IL) code, which is still needed for some scenarios, and the native version of the same code. R2R is only available when you publish an app that targets specific runtime environments (RID) such as Linux x64 or Windows x64.

Advantages

• Improved startup time
  The application will spend less time running the JIT.

Disadvantages

• Larger size
  The application will be larger on disk.

Native AOT deployment

Publishing your app as Native AOT produces an app that's self-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.

The benefit of Native AOT is most significant for workloads with a high number of deployed instances, such as cloud infrastructure and hyper-scale services. .NET 8 adds ASP.NET Core support for native AOT.

The Native AOT deployment model uses an ahead-of-time compiler to compile IL to native code at the time of publish. Native AOT apps don't use a just-in-time (JIT) compiler when the application runs. Native AOT apps can run in restricted environments where a JIT isn't allowed. Native AOT applications target a specific runtime environment, such as Linux x64 or Windows x64, just like publishing a self-contained app.

Limitations of Native AOT deployment

Native AOT apps have the following limitations:

• No dynamic loading, for example, Assembly.LoadFile.
• No run-time code generation, for example, System.Reflection.Emit.
• No C++/CLI.
• Windows: No built-in COM.
• Requires trimming, which has limitations.
• Implies compilation into a single file, which has known incompatibilities.
• Apps include required runtime libraries (just like self-contained apps, increasing their size as compared to framework-dependent apps).
• System.Linq.Expressions always use their interpreted form, which is slower than run-time generated compiled code.
• Not all the runtime libraries are fully annotated to be Native AOT compatible. That is, some warnings in the runtime libraries aren't actionable by end developers.
  
  
  

In .NET Core, both self-contained deployment and Native Ahead-Of-Time (AOT) compilation are methods to package and deploy applications, but they work in different ways and have different advantages.

Self-Contained Deployment:

• In a self-contained deployment, the application and all of its dependencies, including the .NET runtime, are bundled together.
• The output is a platform-specific executable file.
• This allows the application to run on a target machine even if the .NET runtime is not installed.
• However, the application still uses the Just-In-Time (JIT) compiler to translate Intermediate Language (IL) code into native code at runtime.

Native AOT Compilation:

• Native AOT compilation compiles the application into native code at the time of publishing.
• This results in a self-contained executable that does not require the .NET runtime to be installed on the target machine.
• Native AOT apps have faster startup time and smaller memory footprints.
• These apps can run in restricted environments where a JIT isn’t allowed.
• However, not all features in ASP.NET Core are currently compatible with native AOT.

Each of these methods has its own advantages and trade-offs. The choice between them depends on the specific requirements of your application, such as startup performance, deployment flexibility, and platform compatibility.