I think many of you have developed great solutions (in msdn - solution), with many sub-projects. And in this case often becomes a problem of synchronization Nuget packages, build settings, etc. And, of ReSharper here to help little, except that he also begins to be confused in a variety of libraries.
To check the source code has been made an Open Source solution - SolutionCop, which is free to use.
For a start I will give a couple of examples of when not prevented verification of our solutions.
Example 1: The different versions Nuget libraries.
For example, there are three projects: exe, dll1 and dll2. exe refers to both libraries, each of which refers, for example, at RX. But dll1 uses RX 2.2.0, and dll2 - RX 2.2.5. In fact, you can not immediately get an error, because the function signature is more or less the same, moreover, MsBuild often collects projects at one and the same order. However, this configuration can lead to problems that appear after deployment'a when all the unit tests pass (as they refer only to your library), and when the result will prepare a set of files.
Example 2: refers to a project library directly, and not through Nuget.
Again, we take three of our project: exe, dll1 and dll2. For example, we also use more Jetbrains.Annotations, to mark the code NotNull / CanBeNull attributes and getting pretty static analysis. But here's the thing: for dll1 we honestly have downloaded the package version 9.2.0, but we just asked dll2 ReSharper add a link, which he did. As a result, in packages.config dll2 file package with no attributes, which means that if the project will be collected in order dll2 -> dll1 -> exe, then we get an error, because Nuget package download only when collecting dll1!
One can cite a number of examples of different settings in the projects could lead to gay issues. For example, projects for .Net 4.0 and .Net 4.5 can refer to the same packages, but in different libraries in them (see. Nuget help), and then we will again get special effects when building projects. However it is better to move on SolutionCop.
setting
SolutionCop available on Nuget, it is set at the level of the entire solution. After installing the package, you must create an xml file with the rules, set them up and build Verifier in the assembly procedure at the CI.
Step by step:
Create an xml file with the rules (will check himself SolutionCop):
SolutionCop.exe -s "C: \ git \ SolutionCop \ src \ SolutionCop.sln"
After this command near the sln file will SolutionCop.xml file. It lists all the rules, but they are turned off. Consider them later.
Configuring CI server to run SolutionCop (3-4 seconds verified solution with 100 projects) for each build. For TeamCity can even publish status with a more convenient format. For everyone else - have to read Error Output. The application returns 0 if all the rules 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 required if TeamCity does not write the status of unit tests (despite the fact that they were carried out later). It will disable the output SolutionCop case, if all the rules were made.
rules
So, SolutionCop set, he now looks at the decision, but did not check. So list the rules, which can be useful. A detailed description of their use is on GitHub, I just list interesting. For each rule, of course, possible to set exceptions and so on.
WarningLevel. Verifies that all projects have a Warning Level is not below the set.
TreatWarningsAsErrors. Adjacent to the previous. Also synchronizes configuration compilation.
TargetFrameworkVersion. Sihnronizuet .Net version for all projects
SuppressWarnings. Sihnronizuet list of warnings, which the compiler will turn a blind eye.
FilesIncludedIntoProject. It verifies that all the files in the project folder, are included in this project (in addition We point expansion). Incredibly useful rule. For example, once when the wrong git merge with us from the project with unit tests has fallen about a third file. Noticing this, of course, immediately, by the time we missed several bugs. It also helps with the cleaning repozitoroya to avoid hanging heap of files that nobody uses.
ReferenceNuGetPackagesOnly. Prevents be linked dynamically to the library, which is not added as NuGet packages. In fact this patch of Example 2 above.
NuGetPackagesUsage. Defines Nuget packages that can be used. This setting is necessary for the tasks in the product when there are several teams, each with its own repository, they refer to each other as well as on some shared components. And in order to avoid problems when combining code, you can define general rules for all: which versions of packages anyone can use. In this case, all the rules are kept separate from the code in a separate repository.
SameNuGetPackageVersions. It prohibits the use of different packages Nuget in the decision. Correcting the error of Example 1.
NuGetAutomaticPackagesRestore. Verifies that all the projects reduced Nuget packages in the assembly process. Otherwise, a different order of compilation on the CI server can lead to the fact that nuget packages not to load time as a project enjoyed the fact that it is charged depending on other projects.
In fact, in SolutionCop there are a number of other rules that will help clean up the code. I have tried to list those that may be needed almost everyone who is developing on .Net.
No comments:
Post a Comment