S h o r t S t o r i e s

// Tales from software development

The primary reference could not be resolved

leave a comment »

Last week one of my colleagues checked out the project that we’re working on and found that it wouldn’t build on her machine. This seemed rather odd as the project could be built successfully on my machine and on the build server.

This is a Visual Studio 2010 solution with four projects that targets the .NET 2.0 Framework. One of the projects references a common assembly called Vitality.Common.Data.dll containing routines to access MySQL databases.

When she tried to build the solution, one of the projects failed to build and the single error message indicated that namespace specified in a using statement and implemented in one of the other projects, which was referenced, was not found. This was very puzzling as there was no indication that the referenced project was failing to build.

At this point I was ignoring the warning messages and just concentrating on the error message. After a few minutes of unsuccessfull investigation I looked at the warning messages which, initially, seemed to make the problem even more puzzling:

The primary reference “Vitality.Common.Data” could not be resolved because it has an indirect dependency on the .NET Framework assembly “Accessibility, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” which has a higher version “” than the version “” in the current target framework.

As the solution targets the .NET 2.0 Framework and references a .NET 2.0 assembly, why did the warning messages reference .NET 4.0 assemblies ?

But the main puzzle was why this solution could be successfully built on other machines. Using the most basic diagnostic approach, what was different on this machine ?

I vaguely remembered that my colleague had recently been working on a .NET 4.0 project that used the MySQL .NET Connector and guessed that she had installed the .msi package for this. Neither my machine nor the build server had the MySQL .NET Connector installed and relied on the solution including a copy of the referenced MySQL assembly. Could that be the difference ?

Well, an install of the MySQL .NET Connector would almost certainly have put the assemblies in the GAC and this particular version, 6.3.6, includes assemblies built for both the .NET 2.0 and .NET 4.0 Frameworks. Could this be why references to .NET 4.0 assemblies were appearing in the warning messages ?

Suddenly, it made sense…

Project A references Project B
Project B references Vitality.Common.Data.dll
Vitality.Common.Data.dll has a dependency on MySql.Data.dll

There is no direct reference in the solution to MySql.Data.dll so when it’s built this dependency has to be resolved by probing for the assembly. This is where the difference between the machines becomes significant as it appears that the GAC is searched for the dependency, MySql.Data.dll, first and then, if not found, the directory where the directly referenced assembly, Vitality.Common.Data.dll, resides.

So, on both my machine and the build server, the copy of MySql.Data.dll that is in the same directory as the referenced assembly, Vitality.Common.Data.dll is used but on my colleague’s machine it is the copy in the GAC that is used.

The simple solution was to add a reference to the project that referenced Vitality.Common.Data.dll for the copy of the MySql.Data.dll assembly in the same directory as the Vitality.Common.Data.dll assembly. Once this was done the solution could be successfully built.

The only remaining question is why the dependency resolution process selected  the .NET 4.0 version of the MySql.Data.dll assembly from the GAC rather than the .NET 2.0 version…


Written by Sea Monkey

September 27, 2011 at 8:00 pm

Posted in Debugging, Development

Tagged with , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: