Secret ingredients to quality software

SSW Foursquare

Rules to Better .NET Core - 4 Rules

A lot of these rules have originated from the .NET Core Superpowers Tour.

  1. Do you know why you choose .NET Core?

    Cross platform

    .NET Core works on multiple platforms like MacOS, Linux and Windows. So developers can code on their operating system of choice using Visual Studio, Visual Studio for Mac or Visual Studio Code, working on the same code base as developers on a different operating system, and best of all they can also deploy to Linux.


    .NET Core is fast, and you get that performance out of the box.

    dotnet core performance
    Figure: ASP.NET Core easily trounces ASP.NET 4 in number of requests per second (view source)

  2. Do you know the best Unit Testing framework?

    When getting started with unit testing, it is important to use the right tools for the job.

    bestunittest bad1

    bestunittest bad1
    Bad Example: MS Test was the default testing library for previous versions of .NET and Visual Studio but lacked many features that were available in more complete tools like NUnit

    bestunittest bad1

    bestunittest bad1
    bestunittest bad1
    OK Example: NUnit - For previous versions of .NET, NUnit was the best testing library but required work on the Continuous Integration server to get the unit tests to run in a CI environment. One of the key features that NUnit had that MS Test didn't was the TestCase attribute that allows you to specify inline data to be used when invoking that test

    bestunittest bad1

    bestunittest bad1
    Good Example: XUnit comes out of the box with .NET Core and includes most of the great features of NUnit, while also being supported out of the box with Team Foundation Server and Visual Studio Team Services

  3. With .NET Core, we've got a new, extensible configuration system for our projects. This is easily extended and has out-of-the-box support for many configuration sources including JSON files, per-environment overrides, command-line parameters, and environment variables.

    A common source of pain when working in a team is when different team members require different connection strings in order to run the project locally. If the developer modifies settings and then accidentally pushes that change into source control, the app might break for other developers.

    Resolve this by:

    local config file 1
    Figure: #1 Create an appsettings.Local.json file. Set this to be ignored by your source code control system

    local config file 2
    Figure: #2 Add code to apply this configuration file in Program.cs

    Now, any new developer that needs a custom connection string (or any other configuration setting) can create their own appsettings.Local.json file without affecting any other team member’s configuration.

  4. Do you know when to target LTS versions?

    Long Term Support (LTS) versions of .NET Core / .NET 6+ are officially supported by Microsoft for 3 years following release.So when considering which version to target for your application, the “Latest LTS when we first deploy to Production” is often the safest choice.Non-LTS versions have much shorter support lifetimes.

    Deciding which version to target is not always as simple as "always choose LTS".

    In many cases, the expected lifetime of a project is longer than this LTS lifetime so future upgrades to your project must always be considered.

    The ongoing resources planned to work on this product must also be evaluated.

    To help in these decisions, the .NET Core team has released a roadmap for upcoming releases over the next few years. All even-numbered releases will be LTS.

    net schedule
    Figure: The .NET Schedule – from Introducing .NET 5

    Important questions to consider include:

    • What is the planned lifecycle of the project?
    • Will there be ongoing development in the future?
    • How are we planning to distribute and support this project?

      • Web services that are automatically deployed to the cloud will be easier to continually update than a desktop app installed on customer PCs
    • How does my project’s lifecycle align with the .NET release cycle?

    All supported versions of .NET will receive servicing releases and the work to apply these updates should always be factored into the Total Cost of Ownership for any project.

    A few invented scenarios are presented below:

    Example 1

    "It’s November 2020 and we are planning to launch the final version of our ASP.NET Core 3.1 API next week. There is no further planned development work in the next 12 months. If we upgrade to .NET 5 in the final sprint, we would get a performance boost."

    Recommendation: Although moving to .NET 5 could introduce a performance improvement, .NET 5 is not LTS and there is little future development planned. In this situation staying with the LTS .Net Core 3.1 is recommended.

    Example 2

    "It’s November 2020 and Build 4463 of our ASP.NET Core API has just been deployed to Azure via GitHub Actions. We plan to continually develop new feature requests over the next 15 months, Finishing in January 2022”

    Recommendation: When “continual development” is planned, it’s much easier to recommend working against the latest .NET version as it’s released. Upgrading incrementally during active development is often less painful than a larger planned upgrade between LTS versions

    Example 3

    "Once finished, we have no plans for further features for the next 2 years. Our planned launch date is October 2021"

    Recommendation: The plan to reach “feature complete and done” followed by no planned subsequent work seems to suggest that development with an LTS version would be best.
    But if you look at the planned launch date, it’s 1 month before the next LTS release (.NET 6). In this scenario, I would strongly advocate Developing against .NET 5, but leave some spare capacity to perform an update to .NET 6 LTS soon after launch. Then the final, "stable" version will have a much longer support window.

We open source. Powered by GitHub