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

Could not load file or assembly 'CefSharp.Wpf for both x64 and x86; only one works

When I run I get: Could not load file or assembly 'CefSharp.Wpf, Version=41.0.0.0, Culture=neutral, PublicKeyToken=40c4b6fc221f4138' or one of its dependencies. An attempt was made to load a program with an incorrect format.
This means the problem is due to the dlls not being correct bitness.
In version 41.0.0, the nuget package adds dll references to the x86 version which point to the correct path (an x86 folder). There are also another copy of dlls that point to an empty path in the properties panel. The problem is that the x64 version crashes with a bad image error because it is referencing the x86 versions of the dlls.
I have back tracked to 39.0.2 and CefSharp works for me. I have both sets of dlls and where x86 and x64 versions of my application compile and run as expected.
When I upgrade again to 41.0.0 same problem as before. The x64 version will compile though the application uses x86 versions of the dll which crashes when trying to display the first browser. I tried to rebuild all as well as removing the dlls that are copied in automatically and during the compilation the x86 versions are copied in again. (At least I believe this is the case a
I then removed all of the dlls in the references and manually added the x64 versions. The compilation and execution worked correctly as it did with the 39.02 version of CefSharp.WPF.
How can I get both versions to work without having to manually change the dll paths?
Another note: I can use nuget while set to x64 and this makes the opposite of the above problem. Now x64 works and x86 doesn't. The paths of the dlls are now x64 folders.

It turns out, after much tribulation and anguish, I found that the References were not setup correctly in my .csproj. They were defined as being x64 somehow.
<Reference Include="CefSharp, Version=41.0.0.0, Culture=neutral, PublicKeyToken=40c4b6fc221f4138, processorArchitecture=AMD64">
<SpecificVersion>False</SpecificVersion>
<!--<HintPath>..\packages\CefSharp.Common.41.0.0\CefSharp\x64\CefSharp.dll</HintPath>-->
</Reference>
<Reference Include="CefSharp.Core, Version=41.0.0.0, Culture=neutral, PublicKeyToken=40c4b6fc221f4138, processorArchitecture=AMD64">
<SpecificVersion>False</SpecificVersion>
<!--<HintPath>..\packages\CefSharp.Common.41.0.0\CefSharp\x64\CefSharp.Core.dll</HintPath>-->
</Reference>
<Reference Include="CefSharp.Wpf, Version=41.0.0.0, Culture=neutral, PublicKeyToken=40c4b6fc221f4138, processorArchitecture=x86">
<SpecificVersion>False</SpecificVersion>
<!--<HintPath>..\packages\CefSharp.Wpf.41.0.0\CefSharp\x64\CefSharp.Wpf.dll</HintPath>-->
</Reference>
As soon as I commented out the HintPath, it started working correctly. Note that the actual references are defined by the Import at the top of the project.
<Import Project="..\packages\CefSharp.Wpf.41.0.0\build\CefSharp.Wpf.props" Condition="Exists('..\packages\CefSharp.Wpf.41.0.0\build\CefSharp.Wpf.props')" />
<Import Project="..\packages\CefSharp.Common.41.0.0\build\CefSharp.Common.props" Condition="Exists('..\packages\CefSharp.Common.41.0.0\build\CefSharp.Common.props')" />
These .props files setup the actual HintPath that is necessary for it to copy the correct .dlls over to the build folder. I am uncertain as to how my project ended up with the path set incorrectly.

Using Visual studio 2017, winforms application, I encountered the error after upgarding the Nuget package on one machine, uploading to Github, then on another machine, I executed a git a Pull to update my solution file there. Resulted in above error on 2nd machine.
Remedy:
Delete folders in /bin and /obj.
rebuild solution.

Annoying log4net assemly reference issue in vs 2012

Getting following build error.
Error 15 Unknown build error, 'Could not load file or assembly
'log4net, Version=1.2.11.0, Culture=neutral,
PublicKeyToken=669e0ddf0bb1aa2a' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040)'
I dont quite get whats going on.
I tried using GUI for references, it didn't help. Spent 1.5 hours on this already and issue is still present.
I go directly to project file now and the only reference to log4net there is the following:
<Reference Include="log4net, Version=1.2.12.0, Culture=neutral, PublicKeyToken=1b44e1d426115821, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\ExternalDlls\.NET 4.0\log4net.dll</HintPath>
</Reference>
I still get this error. Why does it even mention V1.2.11?
Thanks in advance

Okay got build working finally.
I went through all other projects and did Resharper - Remove unused references action.
After it was done, project started to build.

Can you check what version actually exists in the Path ....\ExternalDlls.NET 4.0\log4net.dll mentioned and see what version is present in GAC.
Remove the version in GAC, remove the below reference the from project file and add it again from the ExternalDlls folder
<Reference Include="log4net, Version=1.2.12.0, Culture=neutral, PublicKeyToken=1b44e1d426115821, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\ExternalDlls\.NET 4.0\log4net.dll</HintPath>
</Reference>

If you are creating a nuget package that is referencing log4net make sure your nuspec file is specifying the correct version of log4net (this is the problem I ran into after log4net released the new build). And make sure that if you don't want the latest version of log4net you encapsulate your version with "[" and "]" so that it doesn't get the latest. See this.. http://docs.nuget.org/docs/reference/versioning#Specifying_Version_Ranges_in_.nuspec_Files
Hope this helps someone.

I am facing this issue today. To solve this problem I deleted log4net.dll file reference from Bin Folder through visual studio. and rebuild the website.
It automatically picks up log4net dll. This solved problem. Reason for this issue was Reference bind through visual studio may not be upto date with the actual file version.

Disk references not seen within build controller

I have various projects which reference assemblies within C:\Program Files (x86). I have installed the assemblies on my build controller in the exact same way and the files are in the C:\, however whenever I trigger a build my controller doesn't find the assemblies.
<Reference Include="GrapeCity.ActiveReports.Diagnostics.v7, Version=7.0.6163.0, Culture=neutral, PublicKeyToken=..., processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
</Reference>
The reference in the project looks like the above, which in my opinion I can understand why the build controller can't find the reference because there are no hint paths.
I have tried changing Copy Local to true and Specific Version to false, this also didn't work. What should I change in my project, build controller or build definition to make the server have scope of the assemblies?

So one way to solve this is to not reference from the GAC.
<Reference Include="GrapeCity.ActiveReports.Diagnostics.v7, Version=7.0.6163.0, Culture=neutral, PublicKeyToken=..., processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
</Reference>
Find this GrapeCity.ActiveReports.Diagnostics.v7.dll.
Where your .sln file resides, create a .\ThirdPartyReferences\ folder.
Copy GrapeCity.ActiveReports.Diagnostics.v7.dll to that directory.
Remove the "gac" reference.
Add the more local .\ThirdPartyReferences\ reference.
Check .\ThirdPartyReferences\ folder into source control.
Make sure .\ThirdPartyReferences\ is "pull down" from source control during the build.
OR
Get "GrapeCity.ActiveReports" installed on the build-server using their install tools.
Which should get into correctly into the GAC on the build server.
I usually choose the first option (my first option above).
I like having a very good handle on what my ThirdParty dependcies are for my build.

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.