I get asked frequently about whether a lower version of .NET Core will run on a machine that only has a more recent version of the .NET Core runtime installed. The short answer is 'No it won't run' but there are a few nuances to this simple answer.

I recently ran into a snag with one of the my Windows Server installs of an upgraded .NET Core 5.0 application. It turns out I didn't install .NET Core 5.0 correctly because I made some bad assumptions of what I needed to install to run my application, even though it previously ran on .NET Core 3.1. Here's more detail on what the failure looks like and how to properly install .NET Core 5.0.

Over the last week I spent some time upgrading several .NET Core Web applications and libraries from .NET Core 3.1 to .NET 5.0. I'm happy to say that this was always a non-event as the process went very smooth for once. In this post I'll talk about what I found and also offer some commentary why we should celebrate this update and push Microsoft to continue along this path.

Custom project templates can be extremely useful in quickly creating new projects especially for extensible applications. They're also great for creating specialized setups to make it quicker to hit the ground running. With the .NET SDK tooling new project templates are now easy to create and this post takes you through the process.

Dotnet Tools offer a simple way to create, publish and consume what are essentially .NET Core applications that can be published and shared using the existing NuGet infrastructure for packaging and distribution. It's y quick and easy to build tools that you can share either publicly or privately. In this article I make a case for why you might use or build a Dotnet Tool and show how create, build, publish and consume Dotnet tools as well as showing some examples of useful tools I've build and published.

I've been upgrading Markdown Monster to run on .NET Core 3.0 and one of the biggest changes is switching to the new .NET SDK style format for all projects. I ran into some issues with the Addin projects that require that output is placed in a very specific output folder and to not include output of all references. In this post describe a couple of ways to control where output goes and how to limit the output that goes to those folders.

I spent a good part of the day today getting Markdown Monster to run on .NET Core 3.0 and in this post I packaged up my notes into a lengthy post with how went through this process. It wasn't exactly quick to make this happen but MM has a few peculiarities that made this process a little bit more trying than it could have been. I'll summarize some thoughts at the end on both the process and the relevance of this process.

Ran into a problem yesterday with a new installation of the .NET Core 3.0 Preview 4 installation. Installed the new preview and found that all of my .NET Core 2.x SDKs were no longer showing. A lot of back and forth later I found that I accidentally installed the wrong bitness SDK - 32 bit vs 64 bit. Here's a quick overview of how and why and why you probably NEVER want to install the 32 bit SDK.

I was surprised to find out that COM Interop works in .NET Core when running on Windows. It's possible to access COM components via Reflection easily enough in .NET Core 2.x. Unfortunately use of the `dynamic` keyword does not work in .NET Core 2.x so for the moment COM interop is limited to using Reflection.

.NET Core doesn't support creating executables directly, but it does have support for **Global Tools** which provide a mechanism to register a console application and make it easily accessible using a simple command line command rather than a complex `dotnet.exe` command.

.NET Core has a number of different runtime downloads that you can grab to install. The combinations of downloads can be a bit confusing and it depends on whether you install a development or runtime environment. In this post I describe what each download contains and what you should use it for.

Microsoft has a long history of not providing a reasonable way of looking up the version of the runtime that is hosting your applications. .NET Core is no different and in this short post I show one way you can capture a descriptive name of the runtime executing that's suitable for displaying in your application's info page.

.NET Core provides a clean configuration system and in ASP.NET Core that code is automatically configured for you. In test and other non-Web projects however you have to manually configure the configuration provider yourself. In this post I look at a couple of ways to set up a configuration provider both using raw configuration objects or by explicitly configuring through the depedency injection system.

.NET SDK style projects no longer support packaging NuGet content into projects as older projects did. So if you need to ship some dependent content with your library you need to find a different way to do so. In this post I look at a specific example of library that requires additional content and look at how to distribute the extra content as well as displaying a readme file to link to instructions when the NuGet package installs

In this post I'm taking another look at using strongly typed configuration settings in ASP.NET Core, using a slightly simpler approach that foregoes using IOptions in favor of directly using a configuration object instance. In the process I review the various approaches as a summary for getting configuration settings into .NET types.

After a long wait .NET Core and ASP.NET Core 2.0 are finally here. This release is a major update from Version 1.0 that brings back a ton of functionality that was originally missing in .NET Core 1.x. With closer compatibility to full framework .NET it's much easier to port existing code to .NET Core, as having a much larger API surface to use in your applications. There are many usability improvements that make it easier to get started using considerable less fanfare. In this post I describe some of what's new and what's great and also a few things that are not so great.

I've been holding off porting any of my full frameworks to .NET Core. With the latest .NET Core 2.0 and .NET Standard 2.0 releases and their vastly larger footprints that match more closely with what we expect of the .NET Framework feature set, migrating looks a lot more appealing. In this post I describe the process of porting one of my general purpose full framework libraries to .NET Standard 2.0 and in the process also creating a multi-targeted project that compiles .NET 4.5, 4.0 and .NET Standard projects.

With the release of the first preview of .NET Core 2 and ASP.NET Core 2.0 I decided to upgrade my AlbumViewer sample application to the latest bits and preview tools. Overall the experience was pretty smooth, but I ran into a couple of breaking changes and a few tooling snags that I'll describe in this post.

It's taken awhile but it seems Microsoft is finally nailing the message for .NET going forward and .NET Standard with its common API specification is a huge part in making sure that the same base library of .NET is available on all .NET platforms. In this post I look at what .NET Standard is, how it works and what some of the surrounding issues and impacts are for the .NET Eco system.