Our continuous integration is a standard setup in which we have a build server which produces a build and then deploys that build to the application servers. Inevitably, we upgrade the .NET Core SDK's on the build servers before we upgrade the .NET Core runtimes on our application servers.
Are versions of the .NET Core runtime forward compatible such that I can always run builds from the latest SDKs on older runtimes? For example, what happens I build with SDK 2.1.500 and run it on Runtime 2.1.3? This is what we're doing in production and nothing seems to have blown up yet but I'm wondering if this is something we should avoid.
Related
I'm accustomed to the Java world: it's generally safe to run an application on a newer JRE that has dependent .jars compiled with older versions of Java.
.Net is a bit stricter. For example, if I build an ASP.NET app with TargetFramework "netcoreapp3.1", then I MUST install ASP.Net Core 3.1 runtime on every host server I deploy the app on. I can't just install .NET 7 on the host server, and expect it to work. Correct?
Q: What about NuGet packages? Do I need to install the corresponding .NET or .NET Core runtimes for every NuGet dependency my app uses?
I would recommend using Docker, or any other container platform like Kubernetes to manage applications like this. It's designed just to avoid situations like this where your application changes to rely on new assets. So you could just basically change the version by just changing a number in your Dockerfile before build and deploy it like any other upgrade. This method is always best practice today. Just swap server application images on your servers for each deployment, no installations.
Alternatively, you could build your application as self-contained (runtime/executable included in your build).
To answer the question, you need the same runtime as your application targers.
I have a big application made in ASP.NET MVC using .NET 5.
We wanted to test the feasibility and the possibility to bring it to .NET 6.
Usually, but not always these kind of operations are mostly painless because you just need to upgrade project framework to from .NET 5 to .NET6 (and vs2019 to vs2022)
Why I can run a web application built with .NET 6 in a server with .NET 5 installed?
Now, I did that upgrade, and to test it, I deployed our application to a test IIS server we have where the application is already up and running, with these installed, which are all part of Microsoft .NET 5.0.6 Hosting Bundle:
-Microsoft .NET 5.0.6 - Windows Server Hosting
-Microsoft .NET Runtime 5.0.6 both x86 and 64
-Visual C++ Redistributables
I then deployed the application with dotnet build command in release mode and deployed on it and to my surprise.... IT WORKED
I was quite sure I had to install .NET 6 hosting bundle or something, but I didn't.
Why?
I remember on the other .NET Framework projects, that if you made a project for a certain version of .NET Framework, but in your code you only used functionalities of the old ones, the project build would run without the need to install the new .NET Framework version.
Example:
I create a Console application which has targetframework "C# 9.0 released with .NET 5.0"
but in the code I don't use any of the new constructs and syntax in c# 9.0 but all the code uses C#8.0 constructs, I could run it on a machine with .NET Core 3.0 because it doesn't use any of the new constructs.
This is what is happening?
It means that I have an application with .NET 6 framework but in reality the server is not upgraded and is running with .NET 5 just because in the code I didn't use any of the C#10 new constructs and syntax?
Thanks
I have .NET Core 2.2 application and wanted to use dotnet-counters to get some data about GC. Unfortunately dotnet-counters doesn't see my app (.NET core process) for some reason. When I run
dotnet-counters ps
It returns nothing (my .NET core application is running of course). I use .NET Core version 2.2.8 and dotnet-counters version 3.1.57502. I tried both standalone and Framework dependend version of application.
The diagnostic tools (dotnet counters, dotnet trace, dotnet dump) rely on new features of the runtime exposing the necessary interfaces. These are only present on .NET Core 3.0 or higher.
This means that a .NET Core 2.2 application cannot be monitored / diagnosed with these tools. You will need to update your application to .NET Core 3.0+
I have some older asp.net core 2.0 programs that are running on a server with a asp.net 2.0 server bundler installed on it. I have recently starting working with asp.net 2.1 and 2.2 and I know that those won't run correctly if I don't have the updated server bundler from Microsoft installed. Will my older programs stop working if I install the new bundlers or will everything continue to work as it does now?
You can have multiple runtime of .Net core running side by side on your server. Here is some documention from Microsoft:
To install applications with dependencies on different versions of .NET, we recommend .NET Core. .NET Core offers side-by-side installation of different versions of the .NET Core runtime on the same machine. This side-by-side installation allows multiple services on the same server, each of them on its own version of .NET Core. It also lowers risks and saves money in application upgrades and IT operations.
https://learn.microsoft.com/en-us/dotnet/standard/choosing-core-framework-server
I couldn't find any answer online so I try it here: What is the difference between the DNX (.NET Execution Environment) and the .NET Core?
I know that the DNX is the SDK and also used to execute code and the .NET Core contains the CoreFX (Libraries) and the CoreCLR (the common language runtime).
But I still don't get what it is precisely about between DNX and the .NET Core.
My understanding is that .NET Core is the core Common Language Runtime and various .NET libraries used in .NET applications. This would be things like Microsoft.AspNet.Server.Kestrel, Microsoft.AspNet.Mvc, Microsoft.AspNet.Tooling.Razor, etc.).
DNX is the .NET executioner, which is responsible for running your .NET application. Basically, you would install one or more DNX (clr, coreclr, mono) versions. Then you would build your application and type something like dnx run or dnx web from the command-line to run your application.
There is also DNVM (the .NET version manager), which is the tool used to maintain (install, upgrade, uninstall, etc.) versions of DNX. You would do this by entering commands like dnvm upgrade, dnvm install <dnx_version>, dnvm uninstall <dnx_version>, dnvm use <dnx_version>, etc.
And then there is DNU (the .NET Utilities manager), which manages the dependencies your application relies on located in your project.json file every time you add/remove new dependencies in your project.json file, dnu restore would need to be run in order to update the dependencies your application relies before running dnx run or dnx web.
I've heard that dnx, dnvm, dnu will all be under dotnet soon as .NET 5 is now being called .NET Core 1.0