Understanding Self Contained Vs Framework Dependent Deployment

Today in this article we shall learn the differences between Self Contained Vs Framework Dependent Deployment i,e, SCD and FDD deployment methodologies. These deployment techniques are generic and can be used for Console or ASP.NET API or WebAPI or any MVC project.

Updated October 2026: a Docker and CI/CD decision section, a single-file, trimming and ReadyToRun section, current .NET 10 support notes and an FAQ.

Today we will cover below aspects in the article,

Applications created using the .NET framework can be published in two different modes, and the mode affects how a user runs your app.

When installing the application to the new environment, if the target machine has the required .NET version already installed then the application built using .NET should work without any issue.

If the required .NET core SDK/runtime is not installed then one can follow any of the below approaches discussed. An approach using Self-content deployment doesn’t require a .NET Core SDK/Runtime to be installed on the target machines.

Let’s see both the approaches in detail,

FDD- Build Application as FDD- Framework-dependent deployment

If you are building an application using Framework dependent deployment (FDD) approach, then it is expected that the target server or environment has the .NET Core SDK and runtime installed.

Publishing an app as FDD produces a cross-platform binary as a DLL file, and a platform-specific executable.

Deployable mainly consist of below,

• Application-specific DLLs or EXE
• Dependencies like NUGET or Third party references
• Resource files if any

Example of Framework-dependent deployment

Below FDD deployment has produced below binaries,

As shown above, my deployable consist of Dlls like ExternalDLL1, ExternalDLL2, and Nuget packages like Newtonsoft, etc

All the system DLLs and supported Runtime/SDK will be used from the below folder on the target machine,

.NET Runtime

C:\program files\dotnet\shared\{runtime-type}\{version}\
C:\program files\dotnet\host\

Example: runtime framework DLLs like hostfxr.dll can be found in the below-shared location depending on the target .NET version used,

Advantages of Framework-dependent deployment

There are below advantages of using this approach,

• Small deployment – With this option, you create your deployable consisting of the actual app and its dependencies i.e mainly these part libraries or NuGet package used by your application.
• Leverage the latest patched runtime.

Disadvantages of Framework-dependent deployment

There are below disadvantages of using this approach,

• .NET Core installation needed – Prior installation of the required .NET Core runtime is needed.
• .NET version may change the behavior of the app – With this option, it is possible that the application will use the latest available version on the target machine which could affect application behavior to some extent.

Example :

Say your application targets .NET 10.0.0 and the machine is later patched to a newer 10.0.x release. The same roll-forward applies. In such cases, your application will start using the 5.0.1 version, since it’s the highest patch and the runtime available for the given major version of 5.0.x.

The above behavior can be changed by using a custom configuration like app roll forward settings.

SCD- Build Application as Self-contained Deployment

If you are building an application using an approach, then you are making your application deployable is self-content, and can run on its own.

This can be achieved by building your application using the below build command,

Self-contained Deployment For Linux

Sample command for self Content Deployment for Linux

dotnet publish -r linux-x64 --self-contained true -c release

Self-contained Deployment For Windows10

Sample command for self Content Deployment

dotnet publish -r win10-x64 --self-contained true -c release

OR

For Windows Server

dotnet publish -r win-x64 --self-contained true -c release

Deployable mainly consist of below,

• Application-specific DLLs or EXE
• Dependencies like NUGET or Third party references
• Resource files if any
• System DLLs
• Runtime/SDK

The user of your app isn’t required to download and install it. NET, as your application, will now have everything to run as self-content.

Self-contained Deployable Example

Below SCD deployment has produced below binaries,

Size of my application deployable now increased to 64 MB due to all application,System DLLS and Runtime/SDK are packaged together.

Advantages of Self-contained Deployable Example

With this approach, you achieve the below advantages,

• The app doesn’t required to download and install. NET.
• Application is isolated from other .NET apps
• The application doesnt use a locally installed shared runtime even if available
• You are able to control which target version you want to use.

Disadvantages of Self-contained Deployable Example

• The large size of deployment -The app includes the .NET runtime and all the dependencies making the output noticeably larger than a framework-dependent one. The app is also responsible for delivering runtime patches to its users.
• .NET version compatibility – Any runtime change, including security patches, requires you to republish with a newer runtime and redeploy. This matters because .NET 8 and .NET 9 reach end of support on November 10, 2026, and a self-contained app keeps its old runtime until you rebuild it.

References:

• Create a Self-contained package for Build and Deployment

Do you have any comments or ideas or any better suggestions to share?

Please sound off your comments below.

Happy Coding !!

---

Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published (2026) best practices and guidelines for software design and development.

---

Which Publish Mode Should You Choose for Docker, CI/CD and Servers?

Use framework-dependent when the machine or base image already supplies a patched .NET runtime. Use self-contained when you can’t install a runtime, or when you need to control the exact runtime version yourself.

This table gives a recommended mode for common targets and the reason for each.

Target	Recommended mode	Reason
Server with a managed runtime	Framework-dependent	One runtime patch covers every app on the box, and deployments stay small.
Docker or Kubernetes	Framework-dependent by default	The shared runtime layer is reused, and a newer base image brings patches.
Desktop app	Self-contained	You can’t assume users have the right runtime installed.
CLI tool	Self-contained, often single-file	Users run one file with no prerequisites. Choose framework-dependent if your users all have .NET.
Air-gapped machine	Self-contained	Nothing can be installed or pulled later, so everything must ship with the app.

How do the two modes work in a container image?

A framework-dependent app sits on the aspnet base image. Its runtime layer is shared between your images, and you get a patched runtime by pulling a newer base image and rebuilding.

A self-contained app fits the smaller runtime-deps base image, which holds only the native libraries .NET needs. This makes sense when you need an exact pinned runtime or a trimmed image. The cost is a bigger app layer that changes on every runtime bump.

How do you patch a self-contained app in a pipeline?

A self-contained app gets a new runtime only when you rebuild on an SDK that carries the patch and redeploy. Nothing on the target machine can fix it for you.

• Watch --no-restore: it can leave you on a different patch than you expected, because the restore step normally decides which runtime pack gets bundled.
• Pin when you must: set RuntimeFrameworkVersion for an exact version, then remember to bump it. A pin you forget is a frozen vulnerability.
• Rebuild on a schedule: patches ship monthly on Patch Tuesday, and out-of-band fixes happen too, like the .NET 10 security update of October 25, 2026. Run a scheduled rebuild and redeploy, not just builds triggered by code changes.

Does the app roll forward to a newer runtime?

Framework-dependent apps roll forward at run time. Self-contained apps never do, because their runtime was chosen at publish time.

Note: Roll-forward is like a shop swapping your usual item for the newer model when yours is out of stock. A self-contained app brought its own item, so no swap happens.

For framework-dependent apps, you control the behavior with the RollForward project property, the --roll-forward option, or the DOTNET_ROLL_FORWARD environment variable.

Why do support dates matter more for self-contained apps?

.NET 8 and .NET 9 reach end of support on November 10, 2026, and .NET 10 is the current LTS. A framework-dependent app on a patched host can move forward by updating the host. A self-contained app carries the old runtime inside it, so it stays unsupported until you retarget, rebuild and redeploy.

Frequently asked questions

Is framework-dependent the default in dotnet publish?

Yes. dotnet publish -c Release produces a framework-dependent app. In .NET 7 and lower, giving a runtime identifier used to imply self-contained. From .NET 8 it no longer does, so add --self-contained true when you want a self-contained app.

Why do I get NETSDK1102 when I trim a framework-dependent app?

Trimming is only supported for self-contained apps, because the trimmer needs to analyse the runtime and framework libraries that ship with the app. A framework-dependent app doesn’t carry those libraries, so the SDK stops with NETSDK1102. Publish with --self-contained true and a RID, then test the result for reflection problems, since trimming can remove code that is only reached through reflection.

How does a self-contained app get .NET security patches?

It doesn’t get them on its own. The runtime is chosen at publish time, from the latest patch the build machine’s SDK knows about, and a deployed app never rolls forward by itself. You must update the SDK, republish and redeploy. Framework-dependent apps pick up patches from the host machine or the base image instead.

Do I need a runtime identifier (RID) for a self-contained publish, and can I make a framework-dependent single file?

Yes to the first: a self-contained publish needs a RID such as win-x64 or linux-x64, because the bundled runtime is platform-specific. And yes to the second: single-file works with framework-dependent apps too. You get a small executable that still needs a compatible runtime installed on the target machine.