Download Asp.net Core Runtime 6
Azucena Mcquay
Currently (.NET Core 1.0), the framework resolver will use the latest patch version available for the major and minor version specified in the runtimeconfig.json but no version lower than the runtimeconfig.json specifies. E.g. a 1.1.2 runtime will be used if the runtime config specifies 1.1.1, but if on only 1.1.0 is available, it will log an error. There is also no version roll-forward across minor versions. So an app with a runtime config set to 1.0.0 will trigger an error if only any 1.1.* is installed.
For .NET Core 2.0, a minor version roll-forward is planned in case no matching minor version is found - if a 1.0.5 and 1.1.2 runtime are installed, an app with runtime config of 1.0.4 will be run on the 1.0.5 runtime. If only 1.1.2 is installed, the same app will be run on 1.1.2. If only 2.0.0 is installed, the same app will not be able to run. See GitHub issue for .NET Core 2+ Version Binding for details and discussion about this change.
For .NET Core 2.0, portable applications will use the patch version 0 by default and self-contained applications will use the latest version that the tooling knows about. This change is being made because tooling (CLI "SDK" / Visual Studio) updates and runtime updates have been released at the same time so apps would require the new runtime to be installed on target systems by default. If that runtime was not installed, an error would occur. This was bad if it takes a few days for hosters to catch up with testing and installing updates. The version can still be enforced / required by setting explicitly.
About packages: The packages that 1.* tooling uses are meta-packages. So referencing Microsoft.NETCore.App or NETStandard.Library would pull in a lot of other NuGet packages. This is no longer the case for .NET Core 2.0 and .NET Standard 2.0 - the packages are flat and contain everything you need. Also, when you create a NuGet package, those packages will no longer be dependencies of the resulting package. They are used for compilation references only, with the exception of Microsoft.NETCore.App knowing which additional packages to pull in for self-contained applications.
Previously, a library built with NETStandard.Library version 1.6.1 would cause consuming .NET Core 1.0 applications to contain a lot of updated DLL files that are actually part of .NET Core 1.1. I do not know if this means that LTS policies will cover or not cover applications that end up with those DLLs. And it is hard to see which .NET Core version they belong to since the package versions they originate from are usually 4.0.*, 4.1.* and 4.3.*.
For ASP.NET Core packages, it is a lot easier since they are versioned 1.0.* and 1.1.* so you can see which "branch" they originate from and you have more control over the versions used by specifying the NuGet packages in the csproj file.
The real dependency here is which version of Microsoft.NETCore.App is written to the yourapp.runtimeconfig.json file. A version of the same major and minor number and same or higher patch number has to be installed, the latest patch version will be used. When the .NET Core 2.0 resolver is installed, alternatively the highest version with the same major number will be used instead, but a version of the same major and minor number will be preferred.
The version of Microsoft.NETCore.App will automatically be inferred from the target framework (e.g. netcoreapp1.0 => 1.0.*, patch version depending on the version of the tooling you use). To override the version, set the property as discussed above.
If new NuGet packages are referenced transitively, e.g. by consuming Newtonsoft.Json 10.0.0 from a .NET Core 1.0 app (see GitHub issue), some extra DLLs might be added to the project's output. These are newer versions of DLLs that are part of the runtime, but override the versions from the runtime.
If you really want to make sure that you don't use any FTS versions, you'd need to explicitly reference all these packages in your csproj file so NuGet will downgrade the version of the packages used (and emit package downgrade warnings).
The problem here is that there hasn't been a case where an issue has not been fixed in 1.0 and 1.1 packages. If this will be an issue in the future when 1.0 and 2.0 are supported but 1.1 no longer, we will have to see how this will be handled case by case. (though there certainly be pressure/requests from the community to release updated 1.1 versions as well even if not covered by Microsoft's support).
If you use a 2.0 or higher version, those implementation packages will be trimmed out of the dependency graph of your app and no longer be considered when deploying. This happens as part of the conflict resolution logic that knows that the new flat package contains the same DLL files as the individual packages.
.NET Core has a number of different runtime downloads that you can grab to install the runtimes and the SDK. It's not immediately obvious what you need, so since I just went through this myself and had a discussion with a few folks at Microsoft (thanks @DamianEdwards and @RowanMiller). I thought I'd summarize if for nothing else than my own reference in the future since I seem to forget what I figured for the last release ?.
If that doesn't work and you get an error, it means that .NET Core is not installed at all. dotnet.exe installs as part of a runtime install and puts itself on the path so you should be able to do dotnet --info if it is installed.
dotnet.exe installs with a runtime install, but it only provides core features to provide info to run and application and provide info about the install: dotnet mydll.dll and dotnet --info. To build, publish or do anything else you need to install the SDK.
It's important to understand that you can have multiple runtimes and multiple SDKs installed and each project can use a different one. The runtime is determined by your project's runtime specifier in the .csproj file:
The SDK is either the last globally installed SDK which is the default, or you can explicitly override the SDK in a global.json placed in the solution root folder. The following explicitly forces my project to use the last RC SDK, instead of the RTM version:
Generally, there should be no need to use a specific lower SDK version as the SDK is backwards compatible and can compile various versions of .NET Core applicatino back to v1.0. IOW, it's OK to use the latest SDK in almost all cases.
If you're on a Windows you're very likely to be using Visual Studio and if you have the latest version of Visual Studio installed you are likely to have the latest SDK, runtime as well as the required IIS hosting components installed.
If you're using Visual Studio you typically only need to update the components below if you need to target a specific version of .NET Core that is not already installed. If you're doing active development, the most likely scenario is that you'll be upgrading to the latest version anyway which is most likely going to match what Visual Studio installed.
The SDK is meant for non-Visual Studio build and management tasks. That's for command line use or if you're not on Windows specifically. The SDK basically provides what you need for a development setup to build and run .NET Core and all dependencies. The SDK is the largest download and it contains everything you need for a given platform.
Effectively it installs the dotnet.exe build tools along with support components. The SDK also installs a fixed version of the .NET Runtime with it which is required to run the SDK tooling. In other words if you download the latest SDK you typically also get the latest runtimes and you don't have to install the matched runtimes separately.
Note it a runtime install does not include the ASP.NET Core meta package runtime dependencies, so if your application references Microsoft.AspNetCore.App or Microsoft.AspNetCore.All you have to seperately download the ASP.NET Core package. However, if you explicitly reference all ASP.NET Core Nuget packages rather than using the meta packages, those packages are deployed as part of your application and it can run with just the runtime.
The runtime alone has no support for dotnet.exe beyond running and info, so you can't build or publish - whatever you use the runtime for has to be a completely pre-compiled and be able to run as is.
As you can see so far the SDK and Runtimes by themselves are usually not the right tool for deployed applications because they don't include everything you need and for this reason - at least on Windows there's a special Hosting Pack download that contains everything you need to run an ASP.NET Core application on Windows.
This is perhaps the most confusing of the packages available because the naming doesn't really describe what it provides. You can think of this package as EVERYTHING except the dotnet SDK tools. This package installs both 32 and 64 bit runtimes, the ASP.NET Core Runtimes as well the IIS hosting components on Windows.
The Windows Hosting pack is specific to Windows and there are no commensurate bundles for Linux or the Mac. On Linux/Mac you can use the SDK download for Dev machines, and .NET Core Runtime + ASP.NET Core Runtimes for typical installations.
Thank you for your information. Honestly, I'm quite confused which version need to be installed. I test .net Core 2 on my localhost and it works. But, when I deployed to my hosting (Asphostportal), it is not stable. Sometimes it will work fine, but sometimes it will throw an error. Is there a bug on .net core? Just curious.
Thanks for the excellent breakdown. This is something I have to be mindful of constantly. Our organization leverages several cloud platforms and even has an internal Cloud Foundry implementation. With Cloud Foundry, I find myself constantly having to be mindful of SDKs and runtimes and have to use the global.json to ensure that what I'm building locally can actually be pushed into a Cloud Foundry container based on what dotnet core buildpack has been applied on the servers and what versions of the SDKs it supports.
93ddb68554