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.
To learn the proper way to setup .NET Framework project, click here.
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: ..dll
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:
Go to the Package tab and fill out the values as shown below.
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.
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). 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 “Run on build” (off by default).
Build Event for Creating 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 sown below.
This information and much more comes from my book Rock Your Code: Coding Standards for Microsoft .NET. 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.