“It works on my computer.”
Troubleshooting the executable of the latest application on an end users computer (be they co-worker, team lead, or high-level stakeholder) may be over with Microsoft’s Self-Contained application feature, available in their new deployment methods since the release of .NET 5 in 2020.
It’s a great option for deploying .NET applications: the self-contained application’s output publishing folder has all the components it needs, even .NET! This means they don’t need even need to download/install the .NET runtime.
It’s a great tool for any Windows Developer’s tool belt, and definitely worth experimenting with, but you may come across some problems that will slow down your production.
Self-Contained Means Big Bytes
The ultimate benefit of a self-containerized application is that it easily deploys an application to an external user. It deploys with all it’s .NET libraries, target runtime, and any app dependencies. That said, you’d likely have to send a software installer program just to install the application.
But a major problem will be the size of the deployment. Since it’s deploying with everything it needs, the download size and hard drive space will be much bigger than an application deployed via a framework-dependent versions.
When distributing to internal users, you are defining the required configuration of your application. This is good: you can set the version of .NET and create platform-specific versions (Windows vs. Linux vs. macOS).
This may be unnecessary, however, as you’re likely distributing internally and any potential users will already have .NET installed.
Self-Contained is Locked Up
When deploying a self-contained application, you’re controlling which version of .NET it is deployed in. This, however, makes it harder to update the version of .NET within the application. You can only update by releasing a new version of the app.
Self-contained automatically increases the complexity of a deployment process (versus Visual Studio deployment or CLI). This will intensify training requirements for maintaining the application, especially when the original author leaves or retires.
For example, what if the size of the application has gotten so big it needs to be trimmed? Who will be responsible for this and how will they do it? The trim reduces the file size, but you must carefully select the correct options to ensure nothing critical is trimmed out. Not to mention; not all project types can be trimmed.
How should you Run a Self-Contained Application?
Self-contained applications also face some logistical problems.
What operating system will it run on? You need to know the OS and chipset (64 or 32 bit) the application will run on and specify such via the .NET Core Runtime Identifier (RID) Catalog.
Will you use runtime roll forward? It will allow your deployed applications to run with any available securities patches during the publishing. It’s a great technology since a self-contained application may be bundled with an older version of the .NET Framework that you expect – and be affected by older security issues. But it’s a bit complicated, as seen on the official documentation…
Should you use ReadyToRun? While this ahead-of-time format will help improve latency and start-up time for application assemblies, it could double or triple the size of an assembly and overall increase the size of the file.
Are the New Deployment Options Ideal for You?
.NET 6 has multiple deployment options available, so you’re not restricted to the self-contained feature. It could be worth a proof-of-concept or two (Microsoft included it for a reason, so why not use it?), but ultimately there’s nothing wrong with publishing framework-dependent applications.
If you’re operating in a CI/CD mindset, like to maintain legacy applications or migrate your NuGet packages, self-contained applications aren’t ideal anyway.
If your team regulates the deployment style of applications as part of a CI/CD process, it’s probably best to just keep doing it that way.
