Visual Studio by default does not set all the appropriate options to help you write rock-solid code. I will show 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. More information, including suggestions for VB.NET, can be found in my coding standards book.
Before creating a project, it’s important to take a few minutes to think about the assembly name since that 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:
Multiple 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:
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.
These are instructions on what is important to fill out in the build settings for projects.
- 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.
- XML Document File should be named: /comments.xml (or the file name of your choice, as I did in this example). This will output XML comments to the same directory as the Output Path.
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.
- Always check “Sign the assembly” to create a strongly named key file. This makes sure the assembly can:
- Be deployed to the Global Assembly Cache(GAC).
- Prevent spoofing(the most important reason)!
- 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.
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.
- If you have a copy of Visual Studio that includes Code Analysis, select “Enable Code Analysis on Build” (off by default).
- 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.
This information and more comes from my book Rock Your Code: Coding Standards for Microsoft .NET. 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 set up .NET Core projects.
If you have any comments or questions, please make them below.