Microsoft.SharePoint

The primary reference could not be resolved because it has an indirect dependency on the framework assembly

Piyush K Singh2 Comments

I was migrating a SharePoint 2010 code base to SharePoint 2013. To do that, the targetFramework has to be changed to 4.0. So I moved the entire code base to a different VM which was running the latest .net framework, 4.5. I then changed the targetFramework of the solution to 4.0. Also, I accordingly modified the corresponding SharePoint dlls which now were being referenced from the folder 15. Finally, when I tried to build the solution, I received the following error:

The primary reference “Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c, processorArchitecture=MSIL” could not be resolved because it has an indirect dependency on the framework assembly
A more detailed explanation was found in the OutPut window:
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): warning MSB3268: The primary reference “Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c, processorArchitecture=MSIL” could not be resolved because it has an indirect dependency on the framework assembly “System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” which could not be resolved in the currently targeted framework. “.NETFramework,Version=v4.0”. To resolve this problem, either remove the reference “Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c, processorArchitecture=MSIL” or retarget your application to a framework version which contains “System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”.
I know that for Microsoft.SharePoint version 15, the targetFramework has to be 4.0 (Full), which is exactly what I was using! So, what caused this issue?

Solution

The solution was to include the following tag
<SpecificVersion>True</SpecificVersion>

for all the assemblies which were causing this issue to the dependent projects. To do that, follow the below steps:

  • Identify the erroneous assemblies. In my case it was the Microsoft.SharePoint & Microsoft.SharePoint.Portal dlls. You can also identify it from the output window of your VS.
  • Next, from the Solution Explorer, unload the corresponding project which are targeting the erroneous assemblies.
  • After unloading, right click the same project and click Edit.
  • Locate the reference of the erroneous assemblies, and append the tag, True. For ex, in my case, after the change, the assembly Reference looked like the following
  • In case you’re targeting a project output from the same solution, instead of a standalone assembly, the resolution will still be the same. The ProjectReference will then look like the following:
  • Finally, Re-Load the project and build. The build will be successful.

Explanation

Specific Version signifies that Visual Studio will only build if it has access to the specific version of the referenced assembly. This kind of error/check is enforced mostly when we implement .net assemblies targeting different versions of .net framework than the targetFramework of the current project. Please note, that the Specific Version property is only a build-time directive, and it has no effect on the run-time version resolution of the referenced assembly. So it’s not gonna affect the behavior or outcome of your program. It’s simply a check enforced while building the project.

Key Takeaways

  • The default value of Specific Version is false.
  • Specific Version is only a build-time directive, and it has no effect on the run-time version resolution of the referenced assembly.
  • Specific Version of a project can also be modified directly from the corresponding property window of the erroneous assembly. However, it is strongly recommended to modify this value only using the steps described above.