Should you have the misfortune of encountering MS Build warning MSB3268, you might be in for a world of hurt. That is exactly what has happened to me this fine day.
The exact problem is:
Microsoft.Common.targets(1360,9): warning MSB3268: The primary reference "<assembly reference>" could not be resolved because it has an indirect dependency on the framework assembly "<assembly" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v2.0". To resolve this problem, either remove the reference "<assembly>" or retarget your application to a framework version which contains "<assembly>"
The scenario is rather striking. It involves Visual Studio 2008 (.Net Framework v3.5) and concerns some differences between that version and its’ successor, Visual Studio 2010 (.Net Framework 4.0). In the former (2008) when a reference was detected with a dependency on a newer version of the .Net Framework it was, in a way, ignored and compilation would continue.
However, in Visual Studio 2010, this dependency is cause for an error, and your solution will not compile. It’s a little surprising that this hasn’t shown up earlier – I was completely surprised to find out this little change.
In our scenario, we have a solution which must target the .Net Framework 2.0 because of a restriction due to the production machines (we can’t upgrade them to later versions of the framework). A common component we use had Microsoft Practices’ Unity compiled into it in January using version Unity 2.0, which (as it turns out) has a deep dependency on .Net 3.5 somewhere.
Unity 2.0’s dependency on .Net Framework 3.5
Dependency Chain
So our .Net Framework v2.0 solution, using this common DLL, would compile fine on VS 2008 (and just log a warning during the build), moving to VS 2010 though and trying to compile an upgraded solution met with a compile error (many, actually) due to this deep dependency. Digging further I uncovered this change between versions. With some help from this thread, I identified a way to force the reference (see below) – which worked – however it was quite unsuitable for our solution.
Solution to MSB3268 in Visual Studio 2010
(from the thread referenced here thread)
Option 1:
Step1: Unload the referencing project targeting .NET 2.0
Step2: Right click the unloaded project and select edit from context menu
Step3: Add <SpecificVersion>true</SpecificVersion> to the reference.
Step4: Reload the project.
Now your should be able to build within the Visual Studio 2010, there could still be a warning as below, but the build can be successful.
Warning 1 The project ‘XXX’ cannot be referenced. The referenced project is targeted to a higher framework version (3.5)
Option2:
Use the command line tool csc.exe to build each of your source file, which won’t prevent the building.
The problem with option #1 is that even if you fix the initial reference, Visual Studio will complain about every subsequent reference in your solution. This means you must alter every reference in the dependency tree.
As you can see, if the reference is in a core assembly in your solution, you end up having to fix all your project and assembly references. Alternatively, you could switch to using csc.exe (option #2) which is a different set of pain. In the end, we simply removed the reference to Unity in the common assembly, and that solved our problem.
An interesting little find though.
