Develop Reference

Weird Error Upgrading ASP.NET MVC from 4 to 5

I'm converting my project from MVC 4 to MVC 5 (and .Net 4 to .Net 4.5.2, which is the real driver of the changes.)
When I run one of my pages I get this error (blank space added by me for easier reading)
[A]System.Web.WebPages.Razor.Configuration.HostSection cannot be cast
to [B]System.Web.WebPages.Razor.Configuration.HostSection.
Type A originates from 'System.Web.WebPages.Razor, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35' in the context
'Default' at location
'C:\windows\Microsoft.Net\assembly\GAC_MSIL\System.Web.WebPages.Razor\v4.0_1.0.0.0__31bf3856ad364e35\System.Web.WebPages.Razor.dll'.
Type B originates from 'System.Web.WebPages.Razor, Version=3.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35' in the context
'Default' at location
'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET
Files\studentportal3g\2204bad2\aece9b3b\assembly\dl3\ad80387c\91adbf51_fc73d101\System.Web.WebPages.Razor.dll'.
When I first saw this is though, Ah easy! Not so much :)
I've gone over every project and made sure it's version is upgraded to MVC 5 which has the 3.0.0.0 version of System.Web.WebPages.Razor.dll.
Clean rebuild, still get the error. No problem , I'll delete the cached temp files.
Clean rebuild, still get the problem. I go back, manually check each version of System.Web.WebPages.Razor.dll, in the references of each project that has a reference to it. I check my folder where I copy dlls to make references to them manually, it's not there.
If my solution doesn't' contain a copy of the DLL or a reference to the DLL, and I've manually deleted the cache folders in 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET
Files\studentportal3g...
Where is the old bad dll coming from? How do I fix this error? How do I prevent it happening again?
Thanks,
Eric-

Visual Studio is a great tool, but it doesn't always make the right choices when it comes to upgrading dependencies, nor does it support every possible option available in MSBuild. Whenever you find yourself in a bind such as this you should manually review and (if necessary) edit your .csproj file in order to resolve it.
The problem isn't that your file exists in the GAC or that it has not been installed by NuGet, the issue is most likely that one of your project files still has a reference to the old version of System.Web.WebPages.Razor version 1.0.0.0, and you need to find all references to it and change them to 3.0.0.0 accordingly.
Right-click on your project node in Solution Explorer and click Unload Project.
Right-click the project node again and click Edit <projectName>.csproj.
Search the file for references to System.Web.WebPages.Razor and update the version and the HintPath accordingly (as shown below). Make sure the HintPath you use actually points to an existing file.
Repeat these steps for all dependent projects in the solution (and any that are in DLLs that are not part of the solution).
Old Reference
<Reference Include="System.Web.WebPages.Razor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<Private>True</Private>
<HintPath>..\packages\Microsoft.AspNet.WebPages.1.0.20105.408\lib\net40\System.Web.WebPages.Razor.dll</HintPath>
</Reference>
Updated Reference
<Reference Include="System.Web.WebPages.Razor, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<Private>True</Private>
<HintPath>..\packages\Microsoft.AspNet.WebPages.3.0.0\lib\net45\System.Web.WebPages.Razor.dll</HintPath>
</Reference>
You should also go through the web.config and /Views/web.config files to ensure that they are not referencing any old versions of this assembly.
NOTE: If the above instructions don't solve your issue, the issue likely is outside of your solution. Most likely there is a 3rd party library that is referencing the old version of the file somewhere. If so, you could attempt to get an updated version of the DLL.
You may also want to check out this question.

It looks like the old DLL is in the Global Assembly Cache (GAC). The GAC is a place where you can store assemblies that can be referenced from several applications on the machine. Click here to read more about GAC.
Use the tool gacutil to update the assembly in the GAC.
The tool is located somewhere under "Microsoft SDKs" folder in Program Files. For me, it was located in
C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\
Open cmd and navigate to the place where gacutil i stored. Then use it like this:
gacutil.exe -i [path to your assebly] -f.
The -i parameter is for indicating where your assembly is located. The -f parameter is used to force an update of the assembly, if it was already there.
Example
Say your DLL is located in
C:\temp\System.Web.WebPages.Razor.dll
Then you would run gacutil.exe -i "C:\temp\System.Web.WebPages.Razor.dll" -f

Newtonsoft.Json.dll being copied from wrong location in the build server

I got some strange issue here, have a software that build normally in Visual Studio, all references where added using NuGet, and the Newtonsoft.Json.dll is in the packages folder and also the reference points to that folder.
When building in the build server, we notice test failures and going further we found that the Newtonsoft.Json.dll copyed in fact was the wrong one, from Blend folder.
From build log:
Copying file from "D:\APPS\Microsoft Visual Studio
12.0\Blend\Newtonsoft.Json.dll" to "D:\TB\2\PLWRO-WebPP\WebPP-Main-Dev-CI\bin\Newtonsoft.Json.dll".
To solve it I renamed Newtonsoft.Json.dll from blend folder for another thing, and then the build got to work normally as expected.
My question is, WHYYY?!?!? Seems that the build is looking for references before in the Blend folder and not in the set location in the hint path - see below.
<Reference Include="Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\packages\Newtonsoft.Json.7.0.1\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>

You could try adding the <private>true</private> element after your HintPath element. This should force the copy to the local directory.
The other part that is interesting, you are looking for an old version (v4.5.0.0) whilst referencing a new version (7.0.1) in your packages.
In Visual Studio, you could try asking Nuget to update the reference to 7.x for this library, and then see if that helps MSBuild pull the library from a more specific location.

Assembly conflict after upgrading package

I have a OneClick program, Project A, that references class library project B. Project B had Json.net version 4.5.0.0 that was upgraded to 7.0.0.0. Upon building project A I get the error messages:
No way to resolve conflict between "Newtonsoft.Json, Version=7.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" and "Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed". Choosing "Newtonsoft.Json, Version=7.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" arbitrarily.
Consider app.config remapping of assembly "Newtonsoft.Json, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" from Version "4.5.0.0" [C:\Program Files (x86)\Microsoft Visual Studio 12.0\Blend\Newtonsoft.Json.dll] to Version "7.0.0.0" [[projectpath]\Newtonsoft.Json.dll] to solve conflict and get rid of warning.
C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3276: Found conflicts between different versions of the same dependent assembly. Please set the "AutoGenerateBindingRedirects" property to true in the project file. For more information, see http://go.microsoft.com/fwlink/?LinkId=294190.
I have cleaned every project in the solution and rebuilt them. I've closed/opened VS, recleaned, rebuilt, same thing. Manually deleted obj + bin folders, same thing.
I've changed the Settings/Publish/Application Files menu to every variation of inclusion/exclusion for json.net.
And finally, I've global searched in Sublime(VS doesn't pick up everything) for 4.5.0.0 and come up with virtually nothing except the json.net references in the manifest files project A creates. I can't seem to find a single lingering reference to the old library, yet it keeps ending up in the manifest upon building.
I've solved my problem by adding <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> in the .csproj's relevant <PropertyGroup>s, but I'm not sure why it works. Can anyone explain to me what's going on? Is this a bad way to solve this problem?

TFS Azure deploy build cannot find the dependent assembly Microsoft.Exchange.WebServices.dll

My Azure deployment script on TFS always fails to locate the assembly Microsoft.Exchange.WebServices.dll when deploying to Azure.
I always get the following warning:
The project '...' is dependent on the following assembly: C:\a\src\Portal\Dev\packages\EWS-Api-2.0.1.0.1\lib\net35\Microsoft.Exchange.WebServices.dll. This assembly is not in the package. To make sure that the role starts, add this assembly as a reference to the project and set the Copy Local property to true.
However, I do not get this warning with our Continuous integration build script. The assembly was added to my web project via the NuGet package EWS-Api-2.0.
I confirmed that copy local is set to true on the assembly reference and the hint path is set properly in the project file and the path specified below was added to TFS.
<Reference Include="Microsoft.Exchange.WebServices, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\packages\EWS-Api-2.0.1.0.1\lib\net35\Microsoft.Exchange.WebServices.dll</HintPath>
</Reference>
I have seemed many people posting on similar issues but none of the solutions I found were applicable or corrected the issue. I ran the build with Diagnostic logging and I did not find anything of value to point to what could be causing the issue.
Does anybody have any suggestions?

Although not an ideal solution, I was able to resolve the issue by downloading the 32 bit version of the assembly from Microsoft here (it wasn't clear if the nuget package was 64 bit or 32 bit). It still wasn't working so I then added it to the project as content and set Copy To Output Directory to Copy if newer and it worked.
Again, I don't consider this an ideal solution. However, it did resolve the issue for me.

Exception while adding controller in MVC3 - file of assembly could not be found

I'm experiencing this weird problem which is driving me nuts. I have a MVC3 project in Visual Studio 2010 which used to work normally. For some strange reason, when I try to add a controller I get an exception. (see screenshot). When I try to add a view, the dialog just closes without notice.
I have added the Griffin.MvcContrib as a NuGet package - which was working properly. I have never used the assembly as mentioned in the exception screen (version 1.1.2.0) - but the latest version, 1.1.2.1
I've performed a full text search within my solution - 1.1.2.0 is not found.
I've emptied caches, reinstalled the Visual Studio project templates, removed the references to Griffin.MvcContrib (uninstall via NuGet), deleted the Bin folder, rebooted my machine, nothing has helped so far. :(
The references in my project file:
<Reference Include="Griffin.MvcContrib, Version=1.1.2.1, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\..\packages\griffin.mvccontrib.1.1.2.1\lib\net40\Griffin.MvcContrib.dll</HintPath>
</Reference>
<Reference Include="Griffin.MvcContrib.Admin, Version=1.0.10.0, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\..\packages\Griffin.MvcContrib.Admin.1.0.10\lib\net40\Griffin.MvcContrib.Admin.dll</HintPath>
</Reference>
<Reference Include="Griffin.MvcContrib.SqlServer, Version=1.0.8.0, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\..\packages\Griffin.MvcContrib.SqlServer.1.0.8\lib\net40\Griffin.MvcContrib.SqlServer.dll</HintPath>
</Reference>
Anybody got any clues on how to fix my IDE/ Project?
Update: steps to reproduce:
Install-Package Griffin.mvccontrib -Version 1.1.2
Install-Package Griffin.MvcContrib.SqlServer
-- everything ok
Install-Package Griffin.MvcContrib.Admin
--> Forces an update of Griffin.mvccontrib to 1.1.2.1
--> Causes the exception as seen in the attached screenshot
Somehow installing the admin module forces an update of mvccontrib.

I know you've searched, but check again, looking in your packages file and your web.config - look for a reference to Griffin.MvcContrib 1.1.2.0
In my experience, assemblies failing to load with that error very often means a version conflict.
If this fails, you might try looking at your project definition in notepad.
Also, check you don't have conflicting versions installed. Sometimes you may have one version in the GAC and be referencing the bare .dll of another, and this can result in a conflict.

The issue stems from a dll that's in your references which has been built against Griffin.MvcContrib 1.1.2.0. So it's going to be difficult to find.
If you can get away with it you can try removing the reference to Griffin.MvcContrib (if you don't need it) or change your packages.config file to refer to the 1.1.2.0 version of MvcContrib instead of 1.1.2.1.
Then go through all of your .csproj files and correct the references to the 1.1.2.0 path instead of the 1.1.2.1 path.

A temporary workaround is to close the solution and just open the project to which you are trying to add the controller. It doesn't fix the conflicting references issue, but it lets you keep going with whatever you're trying to do.