.NET Core 2.1 Update strategy
This post is provided by App Dev Manager Anant Dimri who shares some helpful Q/A around .NET Core patching strategy.
We know that we can create two types of deployments for .NET Core applications:
- Framework-dependent deployment. As the name implies, framework-dependent deployment (FDD) relies on the presence of a shared system-wide version of .NET Core on the target system. Because .NET Core is already present, your app is also portable between installations of .NET Core. Your app contains only its own code and any third-party dependencies that are outside of the .NET Core libraries. FDDs contain .dll files that can be launched by using the dotnet utility from the command line. For example,
dotnet app.dllruns an application namedapp. - Self-contained deployment. Unlike FDD, a self-contained deployment (SCD) doesn’t rely on the presence of shared components on the target system. All components, including both the .NET Core libraries and the .NET Core runtime, are included with the application and are isolated from other .NET Core applications. SCDs include an executable (such as app.exe on Windows platforms for an application named
app), which is a renamed version of the platform-specific .NET Core host, and a .dll file (such as app.dll), which is the actual application.
In a package, you can have .NET core runtime dlls as well as your or 3rd party dlls that you have referenced. When planning for a patching strategy for your .NET core apps, there are certain nuances and questions that come up.
Question: When you publish ASP.NET Core web application that use CodeGen applications, it creates a runtimes folder. Can you help me understand what causes the runtimes directory to be created?
Answer: Runtimes folder is created whenever any native (os/architecture specific) assets are resolved from nuget packages. When the native assets are part of a “shared framework” or “Runtime store”, they get knocked out of the published output because they are in the “platform”. You shouldn’t be able to delete the folder. At startup, the app is supposed to be checked for completeness.
For .NET Core 2.0 and ASP.NET Core 2.0 and higher, we no longer recommend referencing the individual packages. Just target netcoreapp2.0 and reference the Microsoft.AspNetCore.All (or .App in 2.1). Then you can bring in a smaller set of packages that are not in the platform.
Question: When you publish ASP.NET Core web application that uses CodeGen applications, it creates a refs folder. What is this used for?
Answer: The “refs” folder is created when the <PreserveCompilationContext> msbuild property is set to true. This is required for applications that need to preserve the assemblies that were used during compilation, typically because they need to do some compilation at runtime as well, e.g. to compile Razor views.
We set that to “true” by default when the project uses the Microsoft.NET.Sdk.Web (which ASP.NET Core projects should always be doing). However, our Razor packages include a target that during “dotnet publish” pre-compiles the Razor views and then removes the ref folder from the output. This behavior is enabled when the Microsoft.AspNetCore.Mvc.Razor.ViewCompilation package is referenced. It can be further controlled by setting the < MvcRazorCompileOnPublish> property. The Microsoft.AspNetCore.All package pulls in this package so that behavior is enabled by default for all new projects.
In short, if you have Razor views in your application, we recommend configuring the project to compile them during publish, by referencing the Microsoft.AspNetCore.Mvc.Razor.ViewCompilation package. This will improve startup time and remove the “refs” folder from our publish output for you.
Question: How does the minor version roll-forward work based, as outlined by this article https://blogs.msdn.microsoft.com/dotnet/2018/02/02/net-core-2-1-roadmap/
Answer: With 2.0, version 2.0.3 rolls forward to 2.0.5 if its installed. 2.0.3 does not roll forward to 2.1.0 if its installed
Starting with 2.1, version 2.0.3 will roll forward to 2.1 if and only if there is not 2.0.X on the machine that satisfies it. We do our best to maintain compatibility between minor versions but if an application doesn’t work properly when rolling forward to a new minor, we recommend that a runtime with a minor matching the one the application was built for be installed. We prefer the thing that is closest to what the application was built with plus critical maintenance patches.
Special thanks and shoutout to Azure .NET core team and our awesome partner Matthew, https://github.com/mchender
Premier Support for Developers provides strategic technology guidance, critical support coverage, and a range of essential services to help teams optimize development lifecycles and improve software quality. Contact your Application Development Manager (ADM) or email us to learn more about what we can do for you.
Light
Dark
0 comments