检查解决方案中的二进制引用

Question

I'm looking for a way to detect problems with assembly references in a large Visual Studio solution:

• Binary references to bad locations, like a path not in source control or in the output of another project
• Binary references to multiple versions of the same assembly across projects in the solution
• Binary references without a path, that may be redirected to the GAC
• Binary references that should have been project references

The whole story

I work on a large C# project with almost at 200 projects. One of the problems that is creeping in over time is that references to assemblies are added but not always to the same version or to the correct location.

For example, a project may get a reference to System.Web.Mvc without a hint path, making it reference what ever version is in the GAC. Visual Studio (and Resharper) will also offer to add a missing reference but may do so by adding a reference to the output folder of another project.

Now the recent Windows Update catastrophy left some team members dead in the water, unable to build the solution. As you can imagine, this bumped up the priority of assembly reference management for us.

To detect some of the most obvious problems I've already setup an msbuild file that can be included in every csproj file and will detect bad references.

However, new project files will need to be edited manually to include that script. So that will inevitably be forgotten.

What I would really like is to check all project files in a solution for 'bad' references during the continuous build, so that all projects will be checked always.

I've been googling for a solution like this for some time and found lots of static analysis and code analysis tools but nothing to analyze project files in a solution.

So, before I go off and roll my own solution, is there a way to do this already?

Update

In order to clean up the code base I've created a bit of ScriptCS code that'll scan all csproj files for referenced to assemblies in Nuget packages and fix them. It's up on GitHub .

Answer 1

You can create a NuGet package where the sole purpose is incorporating a custom .targets file into a project. I recently used this strategy to solve another problem (error messages for missing .snk files).

• Testing strong names of NuGet-distributed assemblies
• Rackspace.KeyReporting source code

If you create a similar package, it's easy to right click on your solution node and verify that it is installed in all of your C# projects.

If your analysis is more complicated and requires the use of an assembly (custom build tasks) in addition to the .targets file, you can use an approach like I use for the Antlr4 NuGet package, which contains build tasks, resources, and custom .props and .targets files, but no actual assemblies that are referenced by the project it gets installed in.

• ANTLR 4 C# Target source code (includes the Antlr4 package source and build scripts)

Answer 2

Instead of adding it to all projects in your solution, why not create some kind of test (unit test, build file, whatever) that can take a project file as input, parse it, and throw an error if OE or more references are incorrect. Much easier than adding (and checking out, committing etc) custom build steps to project files.

Even if you would use a nuget package as proposed earlier, you'd still have to check manually whether all your projects (200 projects? Really?) Reference the package.