Netcoreapp2.2 Download

[Norine Wiltshire]

Nowthat .NET Core 3.1 is out just this last week and it is a "LTS" or Long Term Support version, I thought it'd be a good time to update my main site and my podcast to .NET 3.1. You can read about what LTS means but quite simply it's that "LTS releases are supported for three years after the initial release."

I'm not sure about you, but for me, when I don't look at some code for a few months - in this case because it's working just fine - it takes some time for the context switch back in. For my podcast site and main site I honestly have forgotten what version of .NET they are running on.

First, it seems my main homepage is NET Core 2.2. I can tell because the csproj has a "TargetFramework" of netcoreapp2.2. So I'll start at the migration docs here to go from 2.2 to 3.0. .NET Core 2.2 reaches "end of life" (support) this month so it's a good time to update to the 3.1 version that will be supported for 3 years.

and my 3.0 updated csproj. You'll note that most of it is deletions. Also note that I have a custom IISUrlRewrite.xml that I want to make sure gets to a specific place. You'll likely not have anything like this, but be aware.

Some folks are more little methodical about this, upgrading first to 3.0 and then to 3.1. You can feel free to jump all the way if you want. In this case the main breaking changes are from 2.x to 3.x so I'll upgrade the whole thing all in one step.

I compile and run and get an error "InvalidOperationException: Endpoint Routing does not support 'IApplicationBuilder.UseMvc(...)'. To use 'IApplicationBuilder.UseMvc' set 'MvcOptions.EnableEndpointRouting = false' inside 'ConfigureServices(...)." so I'll keep moving through the migration guide, as things change in major versions.

Per the docs, I can remove using Microsoft.AspNetCore.Mvc; and add using Microsoft.Extensions.Hosting; as IHostingEnvironment becomes IWebHostEnvironment. Since my app is a Razor Pages app I'll add a call to servicesAddRazorPages(); as well as calls to UseRouting, UseAuthorization (if needed) and most importantly, moving to endpoint routing like this in my Configure() call. I also move the call to bring in HealthChecks into the UseEndpoints call.

I also decide that I wanted to see what version I was running on, on the page, so I'd be able to better remember it. I added this call in my _layout.cshtml to output the version of .NET Core I'm using at runtime.

And that smells weird to me. Turns out there's an overload on AddIISUrlRewrite that might be better. I don't want to be manually opening up a text file and streaming it like that, so I'll use an IFileProvider instead. This is a lot cleaner and I can remove a using System.IO;

And that's it. Followed the migration, changed a few methods and interfaces, and ended up removing a half dozen lines of code and in fact ended up with a simpler system. Here's the modified files for my update:

ASP.NET Core apps can rely on a runtime that is already installed in the Azure App Service or one can do a "self contained" install. My web site needs .NET Core 3.1 (LTS) so ideally I'd change this dropdown in General Settings to get LTS and get 3.1. However, this only works if the latest stuff is installed on Azure App Service. At some point soon in the future .NET Core 3.1 will be on Azure App Service for Linux but it might be a week or so. At the time of this writing LTS is still 2.2.7 so I'll do a self-contained install which will take up more disk space but will be more reliable for my needs and will allow me full controll over versions.

I am running this on Azure App Service for Linux so it's running in a container. It didn't startup so I checked the logs at startup via the Log Stream and it says that the app isn't listening on Port 8080 - or at least it didn't answer an HTTP GET ping.

It's important to make sure that your SDK - the thing that builds - lines up with the the runtime version. I have an Azure DevOps pipeline that is doing the building so I added a "use .NET Core SDK" task that asked for 3.1.100 explicitly.

Now my CI/CD pipeline is building for 3.1 and I've set my App Service to run on 3.1 by shipping 3.1 with my publish artifact. When .NET Core 3.1 LTS is released on App Service I can remove this extra argument and rely on the Azure App Service to manage the runtime.

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

I've been working on a project using .Net Core 2.2. During the course of development I needed to add an SQL Database project to the solution. Everything was building correctly on my local machin, however, the build started failing when I committed and pushed to Azure Devops. The initial issue was that the SQL Database project cannot be built using dotnet build. I tried solving this by switching to VSBuild in my pipeline, however, this caused a new error "This version of Microsoft.AspNetCore.App is only compatible with the netcoreapp2.1 target framework. Please target netcoreapp2.1 or choose a version of Microsoft.AspNetCore.App compatible with netcoreapp2.2."

I was confused since my app was compiling correctly on my local machine, and this was also compiling correctly on my co-workers machine. At first I thought the issue was related to the build agent, however I could also build the app correctly from Visual Studio on the build agent. I also tried switching to a hosted agent, however, this did not solve the problem.

After a number of hours searching for a solution, I stumbled across a suggestion to update the Nuget version being used to execute the pipeline. This suggestion was in a github issue. It turns out that I did not include the step to update Nuget when I changed the azure-pipelines.yml file to build using VSBuild instead of dotnet build. All I needed to do was add the below step as the first step of the pipeline and the issue disappeared.

Then I remembered that I had experienced *some *sort of build errors, as stated above, and tried to run a dotnet restore on my development machine, disabling parallel execution and turning verbosity to full diagnostics:

I found the target _GenerateDotnetCliToolReferenceSpecs in the file C:\Program Files\dotnet\sdk\6.0.101\NuGet.targets, and it sets the DotnetCliToolTargetFramework build variable to a default value if it is not set already. The default value may be, depending on your installation, netcoreapp1.0, netcoreapp2.2, or some other version.

Also when I visit a smart razor pages like /actions, I will get the same error unless I manually add the trailing / then it works. I have reviewed sample projects and documentation and running out of options.

I was able to reproduce the issue locally by simply publishing the web app locally and then from the output directory running the command dotnet MyApp.dll. This behavior is the same on netcoreapp3.1 and netcoreapp3.0. If I revert my code to netcoreapp2.2, smart routing razor pages work properly after publishing.

So to update the situation, my code from the IDE will behave normally in netcore 2.2, 3.0 and 3.1. However I get different behavior after a plain vanilla dotnet publish locally on my Macbook Pro. This behavior also occurs when published to Azure App Service for both Windows and Linux.

I have reviewed the documentation @ -us/dotnet/core/run-time-config/compilation which details the differences in compilation between 2.2 and 3.0 and set all properties to false in my project files but smart razor pages continue to fail after publish.

Further debugging, I ran my app with netcoreapp3.0 and used the ?virtualPathCount to see all the files in the virtual path, on my app and the Validation app, I could see no files with .cshtml as the file extension. However when I swapped my app to netcoreapp2.2, I could see razor files in the virtual path list. Seems like their may be a bug in regards to netcore 3 and razor files.

Thanks Microsoft! So it seems the MvcRazorCompileOnPublish project property is no longer supported or is not behaving properly with 3.0 and above, see for more details. The solution to this problem is as follows:

We have a set of services that we are migrating to dotnet core and NServiceBus7 at the moment. We have a wrapper project that facilitates configuration of endpoints which references NServiceBus.Persistence.Sql (4.5.1). From the actual service endpoints in dotnet core (targeting netcoreapp2.2), we reference our own wrapper assembly, which brings in NServiceBus.Persistence.Sql via transitive nuget dependency.

3a8082e126