Rules to Better .NET Core

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

Hold on a second! How would you like to view this content?
Just the title! A brief blurb! Gimme everything!
  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.
    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.​
    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
    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
    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. Do you add a local configuration file for developer-specific settings?

    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:

    Figure: #1 Create an appsettings.Local.json file. Set this to be ignored by your source code control system
    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.