Cannot start the website because administrative privileges are required to bind to the hostname or port

This error was thrown when I ran the newly downloaded BlogEngine.NET code from Visual Studio 2015.
First thing first, this has got nothing to do with ‘Run as administrator‘ option. The error states that there is a permission issue on the port on which IISExpress was attempting to run the site. I hadn’t changed anything to the original code base. So it was apparent that the port setting must have got imported. My understanding was that Visual Studio auto manages this setting, i.e., if the attempted port is busy, then VS automatically finds the next available slot. As it turned out, this is not the case.

 
Anyways, the solution is to remove the old references of the url (IISUrl) and the port (DevelopmentServerPort) from the csproj file. Apparantly, if you don’t provide any specific url & port, Visual Studio will automatically look for an available port. Yes! automatic.

Following are the steps to accomplish the same:

  • First, ensure that, ‘Apply server settings to all users (store in project file)‘ is checked.
  • From the Solution Explorer in Visual Studio, right click the web project and select ‘Unload Project‘.
  • Next on the same project, right click and select ‘Edit‘.
  • Find the xml tags and and remove them.
  • Reload the project and run.
As you can see in the address bar, the site’s running and is doing so on a different port.

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.