Devising a naming convention for .NET projects
When structuring repositories it helps to document your naming convention for projects. It helps establish a pattern and practice for the team, ensuring consistency and reducing mental burden on working across codebases. As you add new components you may extend the naming convention or adjust it, but you can add to your CI process checks for projects that don't fit the naming convention.
Be careful about having a naming convention that solely uses a technology and\or brand name. Some toolsets can use internal concepts that misbehave. One such example is Xamarin Forms when using the namespace "Android" as demonstrated by [James Montemagno's December 2020 blog post](https://montemagno.com/dont-put-android-in-your-namespace-in-xamarin-apps/).
This is not meant to be definitive, it's an example pattern. You may be using a tech stack that has different concepts ranging from COM+ libraries, device drivers to plug in's for web browsers or applications.
|Project Name Suffix||Description|
|?.Client||Strongly Typed Client Logic. i.e. Http clients|
|?.DotNetTool||Dot Net Core Command Line Tool|
|?.Server||Shared Server Logic|
|?.Shared||Shared Client \ Server Logic|
|?.WebSocketApp||Web Socket Application (If using one and splitting from WebApp \ WebApi app)|
|?.Testing||Reusable Testing logic for use in Unit Tests and Integration Tests|
|?.UnitTests||Unit Tests for the whole solution|
|?.IntegrationTests||Integration Tests for the whole solution|
|?.Benchmarks||Benchmarks for the whole solution|
|?.MsiInstaller||Windows MSI installer|
|?.ForAndroid||Reusable logic for use in a platform such as Android whilst avoiding toolchain issues.|
How do you check the naming convention automatically?TODO.