Properly Setting Up .NET Framework Projects

Visual Studio by default does not set all the appropriate options to help you write rock-solid 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,

dotNetTips.App.Ads.DataAccess
dotNetTips.Utilities.Core.Windows
Microsoft.Build.Utilities.Core
System.Web
System.Web.Services
System.Windows.Forms

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

 

 

Assembly Information

 

It’s important to fill out all the application info settings like name, copyright, version number and more. In the .NET Framework, go to the Application tab in the project settings and click on Application Settings and fill in all the fields shown below.

 

 

Build Settings

 

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

 

1. Treat warnings as errorsin 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 commentsto the same directory as the Output Path.

Signing Settings

 

Signing your assemblies, especially DLL’s 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.

 

1. 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 go 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 are design, 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.

 

1. If you have a copy of Visual Studiothat includes Code Analysis, select “Enable Code Analysis on Build” (off by default).
2. In “Rule Set”, choose the appropriate rule set for your project or make a custom one. Generally, I choose “Microsoft Managed Recommended Rules” for all DLL’s and “Microsoft All Rules” for EXE’s including ASP.NET.

Summary

 

This information and more comes from my book David McCarter’s .NET Coding Standards. The next time you create a new project in the .NET Framework, I hope you will use this info to set it up. My next article will be on how to properly setup .NET Core projects.

 

If you have any comments or questions, please make them below.