SolutionCop

Hi habr! The main discussion will be about developing on .Net, that is, using Microsoft Visual Studio, ReSharper, Nuget, etc.

I think many of you have developed large solutions ( in msdn - solution ), with many subprojects. And in this case, the problem of synchronization of Nuget packages, build settings, etc. often became common. Moreover, ReSharper will help here weakly, except that he, too, will become confused in the many libraries used.

To verify the source code, an Open Source solution was made - SolutionCop , which is free to use.

To begin with, I will give you a couple of examples when we would not interfere with checking our solutions.

Example 1: Different versions of Nuget libraries.

For example, there are three projects: exe, dll1 and dll2. exe refers to both libraries, each of them refers, for example, to RX. But dll1 uses RX 2.2.0 , and dll2 uses RX 2.2.5 . In fact, it’s not at all possible to get an error, since the function signatures are more or less the same, moreover, MsBuild most often collects projects in the same order. However, such a configuration can lead to problems that will appear after the deployment, when all the unit tests pass (because they refer only to their library), and when the resulting set of files will be prepared.

')

Example 2: the project refers to the library directly, and not through Nuget.

Again, take our three projects: exe, dll1 and dll2. Suppose we also use Jetbrains.Annotations to mark the NotNull / CanBeNull code with attributes and get pretty static analysis. But bad luck: for dll1 we honestly downloaded the package version 9.2.0 , and in dll2 we just asked ReSharper to add a link, which he did. As a result, there is no package with attributes in the packages.config file dll2, which means that if the project is built in the order dll2 -> dll1 -> exe, we will get an error, because the Nuget package will be downloaded only when collecting dll1!



There are some more examples where different settings in projects can lead to hilarious problems. For example, projects for .Net 4.0 and .Net 4.5 can refer to identical packages, but to different libraries in them ( see Nuget help ), which means we will again receive special effects when building projects. However, we better go to SolutionCop.

Installation

SolutionCop is available on Nuget , it is installed at the level of the entire solution. After installing the package, you need to create an xml file with the rules, configure them and embed the checker in the build procedure on the CI .

Step by Step:

1. Create an xml file with the rules (we will check the SolutionCop itself):
   
   
   
   SolutionCop.exe -s "C:\git\SolutionCop\src\SolutionCop.sln"
   
   
   
   After this command, the SolutionCop.xml file will appear next to the sln file. It lists all the rules, but they are all turned off. Consider them later.
2. We configure the CI server so that SolutionCop is launched on every build (a solution with 100 projects is checked for 3-4 seconds). For TeamCity, you can even publish status with a more convenient format. For everyone else, you’ll have to read Error Output. The application will return 0 if all the rules have been executed successfully. So, the command line for TeamCity:
   
   
   
   SolutionCop.exe -s "C:\git\SolutionCop\src\SolutionCop.sln" -b TeamCity --suppress-success-status-message.
   
   
   
   The last argument is necessary if TeamCity does not write the status of the unit tests (despite the fact that they were executed later). It will disable SolutionCop output in case all the rules have been executed.

rules

So SolutionCop is configured, it now looks into the solution, but does not check anything. And therefore I will list the rules that may be useful. A detailed description of their use is on GitHub , I just list the interesting things. For each rule, of course, you can set exceptions, etc.

• WarningLevel . Checks that all projects have a Warning Level not lower than the specified.
• TreatWarningsAsErrors . Adjacent to the previous one. Also synchronizes the compilation setting .
• TargetFrameworkVersion . Sichronizuet .Net version for all projects
• SuppressWarnings . Sichronizuet a list of warnings to which the compiler will turn a blind eye.
• FilesIncludedIntoProject . Checks that all files in the project folder are included in this project (additionally the extension is indicated). Incredibly useful rule. For example, once with the wrong git merge, about a third of the files fell out of the unit test project. Noticed this, of course, not immediately, by that time we had already missed several bugs. It also helps with clearing the repository to avoid heaps of hanging files that no one uses.
• ReferenceNuGetPackagesOnly . Forbids dynamically linking to libraries that are not added as NuGet packages. In fact, this is a correction of Example 2 above.
• NuGetPackagesUsage . Defines Nuget packages that can be used. This setting is necessary for tasks, when there are several commands in the product, each has its own repository, they refer to each other, as well as to some common components. And to avoid problems when combining code, you can define general rules for everyone: which versions of packages you can use to whom. In this case, all rules are stored separately from the code, in a separate repository.
• SameNuGetPackageVersions . Forbids the use of different Nuget packages in the solution. Error correction from example 1.
• NuGetAutomaticPackagesRestore . Verifies that all projects restore Nuget packages during the build process. Otherwise, a different compilation order on the CI server may lead to the fact that nuget packages will not be loaded on time, as some project used the fact that its dependencies load other projects.

In fact, there are a number of other rules in SolutionCop that will help clean up the code. I tried to list those that may be needed by almost everyone who develops on .Net.