1

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.

Community
  • 1
  • 1
Marnix van Valen
  • 13,265
  • 4
  • 47
  • 74
  • 3
    *Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.* – EZI Oct 16 '14 at 20:48
  • 3
    @EZI I'm asking for a concrete solution to a concrete software development problem, I'd say that qualifies as a StackOverflow topic – Marnix van Valen Oct 16 '14 at 20:50
  • We had kind of a related problem. Over time our solution would end up with two or three versions of the same NuGet package because people would just install whatever package was most recent instead of using the existing version. Anywho... I ended up writing my own tool to analyze the packages and identify any duplicates. I suspect you're going to have to do the same thing. – Craig W. Oct 16 '14 at 20:54

2 Answers2

3

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).

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.

Sam Harwell
  • 97,721
  • 20
  • 209
  • 280
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.

brijber
  • 711
  • 5
  • 17