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

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

Validate a String to be in Guid Format in .net C#

Initially, I was using a wrong mechanism to validate a string to be in GUID format. I was doing the following:

string wrongString = String.Empty;
bool IsCorrectGuid = false;
try
{
    Guid guid = new Guid(wrongString);
    IsCorrectGuid = true;
}
catch(FormatException){}

However, try-catch is an expensive process so, if you have huge no. strings to validate and most of them will not be a Guid then, this is a very bad way of validation.

The correct way is to use Regex, and if you are working on .Net 4.0 or higher then, you can also use the Guid.TryParse method to achieve the same goal. Following I have demonstrated to validate the string in both ways.

Guid.TryParse

string correctString = Guid.NewGuid().ToString();
Guid guid;
bool guidResTrue = Guid.TryParse(correctString, out guid);

Regex

string correctString = Guid.NewGuid().ToString();

//returns true for correct format, case in-sensitive
Regex isGuid = new Regex(@"^(\{){0,1}[0-9a-fA-F]{8}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{12}(\}){0,1}$", RegexOptions.Compiled);
bool guidResTrue = isGuid.IsMatch(correctString.ToUpper());

Of course, Guid.TryParse should be the preferred way of doing it if, you’re using .Net 4.0 or higher.

Unrecognized attribute ‘targetFramework’ error is encountered for Asp.Net 4.0 site while Deploying it to the IIS or GoDaddy

This error is usually thrown when you try to deploy a Asp.Net 4.0 to IIS whose App Pool is targeting the .Net 2.0. You can confirm that by checking the last line of your error page. This is where running the .net version is displayed.

To resolve it, just do the following

For IIS

Make sure .Net 4.0 is registered in IIS. To do that run the aspnet_regiis.exe tool from the command prompt having administrative rights.
The tool is located at C:\Windows\Microsoft.NET\Framework64\v4.0.30319.

Now in the command prompt run the command aspnet_regiis.exe -iru.

We’re using iru because it Installs this version of ASP.NET. If there are any existing applications that uses ASP.NET, it will not change IIS configuration to use this version. More Info

Next open IIS Manager. Go to your sites app pool. Select Basic Settings and change the framework from 2.0 to 4.0.

For GoDaddy

For GoDaddy, you have to select from the menu bar, More => IIS Management. There at the top you’ll see your sites current .net version with an option to modify.

Select it and change the .Net version from 2.0 to 4.0.

Now here’s an issue. Even if you see your version as 4.0/4.5 still, I recommend you to change the version first to 2.0 and then again back to 4.0. This issue has arisen in the past that the GoDaddy IIS is showing the .Net Framework as 4.0 but somehow internally, it’s still pointing to 2.0. You can confirm the version of the .net environment by looking at the last line of the error page [highlighted above] Just remember to manually recycle the app pool after each version change.

That’s it. The IIS is now targeting the framework .net 4.0.