Properly Setting Up .NET Core Projects

Visual Studio by default does not set all the appropriate options to help you write rock-solid .NET Core code. Below are the recommendations that your team should use for C# projects. All the following recommendations are for Visual Studio 2019. If you have an older version, most of this should still apply.

Application Information

Before creating a project, it’s important to take a few minutes to think about the assembly name since that usually becomes the root namespace. This also is the default name of the EXE or DLL created during the build process.

The name should follow this format <Company>.<Component>.dll

Multiple <Component> names can be used separated by a period. For example.

  • DevExpress.UI.Xaml.Ribbon
  • dotNetTips.Dev.Utility.App
  • Microsoft.AspNetCore.Components
  • Microsoft.Build.Utilities. Core
  • Microsoft.VisualBasic.ApplicationServices
  • Windows. AI.MachineLearning

Here is how I named one of my open-source projects,

Assembly Name

Package Information

Go to the Package tab and fill out the values as shown below.

Package

These settings are not only important for the version number, but other values are used by .NET for things like the proper location to store application data.

Build Settings

These are instructions on what is important to fill out in the build settings for projects.

Build Settings

  1. Treat warnings as errors in Release or Debug Build. This will make sure that warnings are also fixed. This is advisable because they could seriously affect the code.
  2. XML Document File should be named: /comments.xml (or the file name of your choice). This will output XML comments to the same directory as the Output Path.

Signing Settings

Signing your assemblies, especially DLL is very important for many reasons. It’s the only way to create a “unique” assembly in .NET that is digitally signed which means it’s more secure.

Signing Settings

Always check “Sign the assembly” to create a strongly named key file. This makes sure the assembly can.

  1. Be deployed to the Global Assembly Cache(GAC).
  2. Prevent spoofing(the most important reason).
  3. Easier to apply Code Access Security (CAS).

To learn more about signing, read the “Manage assembly and manifest signing” post on the docs.microsoft.com site.

Code Analysis

How sound is the code you wrote? Did you know you can check it right from Visual Studio using Analyze? If you aren’t using this FREE code analysis, then stop now and turn it on in all your projects!

Turning Analyze on will analyze the code during the build process for the project or solution. This is not only important to fix bugs in the code but doing it during the build process while you are coding is a lot cheaper than if it’s found later or even worse when a user reports it. Some of the categories of violations that Analyze checks for our design are globalization, naming, performance, security, usage, maintainability, portability, and reliability.

If you haven’t had this turned on in projects, you might have a lot of violations reported. This might prompt you to go back and turn it off… Don’t!! It’s very important to fix these violations before the next release! It might be painful in the beginning, but in the end, your code will be much better off for it.

Code Analysis

If you have a copy of Visual Studio that includes Code Analysis, select “Run on build” (off by default).

Build an Event for creating a NuGet package

In .NET Core, it’s simple to create a NuGet package from your DLL projects. To make it easier for me to test my NuGet packages before I upload them to the site, I use the build event script below to pack and copy them to a local folder.

if $(ConfigurationName) == Release (
    dotnet pack "$(ProjectPath)" --no-build --include-source --include-symbols --output "c:\dotNetTips.com\NuGet"
)

Then go to “Manage NuGet Packages for Solution” and create a package source that points to the folder (like the one above) as shown below.

NuGet Packages

Summary

This information and much more comes from my book David McCarter’s .NET Coding Standards. The next time you create a new project in the .NET Core, I hope you will use this info to set it up. If you have any comments or questions, please make them below.


Similar Articles
McCarter Consulting
Software architecture, code & app performance, code quality, Microsoft .NET & mentoring. Available!