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
Related
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?
So I cleaned up some DLL references in an ASP.NET MVC project, I deleted the DLLs in the bin and updated source control to remove the DLLs from source control. I copy all the references to bin on build now, the right way. But when I run localhost I get the error:
Could not load type 'Microsoft.Owin.Security.AuthenticationDescription' from assembly 'Microsoft.Owin, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
So I started comparing DLLs on the server (where the website is working), to my local bin directory. If I copy and replace Microsoft.Own from the server and overwrite my local version, the website works again, error gone.
The thing is the versions of the DLLs are exactly the same, see the following screen shot:
On the left is my local copy, and on the right is the version from the server.
If I look at my References for the ASP.NET MVC Website, I see that Microsoft.Own is located at:
..\packages\Microsoft.Owin.2.1.0\lib**net40**\Microsoft.Owin.dll
And Copy Local is set to True, see screen shot:
So next I deleted the reference for Microsoft.Owin.2.1.0 and tried to readd using the net45 version of Microsoft.Owin.dll instead. So I browsed to ..\packages\Microsoft.Owin.2.1.0\lib**net45**\Microsoft.Owin.dll
But when I went to check the Properties for Microsoft.Owin, under References, the path was still
..\packages\Microsoft.Owin.2.1.0\lib**net40**\Microsoft.Owin.dll
So I then went to my csproj file and saw the following entry:
<Reference Include="Microsoft.Owin.Security, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\packages\Microsoft.Owin.Security.2.1.0\lib\net45\Microsoft.Owin.Security.dll</HintPath>
</Reference>
And in my web.config my targetFramework is 4.5:
<compilation debug="true" targetFramework="4.5">
So finally, I copied and pasted the Microsoft.Owin.dll on the server, that works to
..\packages\Microsoft.Owin.2.1.0\lib**net40**\Microsoft.Owin.dll and ..\packages\Microsoft.Owin.2.1.0\lib**net45**\Microsoft.Owin.dll
To overwrite the package DLL being copied when I Rebuild and STILL I get the error:
Could not load type 'Microsoft.Owin.Security.AuthenticationDescription' from assembly 'Microsoft.Owin, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
Again, if I copy the Microsoft.Owin.dll that is the same version as my local copy, and overwrite my local copy of Microsoft.Owin.dll in the bin, my ASP.NET MVC starts working again, until I build again that is of course.
First check both dll size is same?If size is different then dll are different.
Follow following steps.
Open the project
Remove dll.
Build project now. You will get error.
Close project
Open project again
Don't build project
Clean solution
Add dll and reference
Build project
You will get success
It is possible that some assembly file in "bin" directory which is depended on the error loading assembly.So you should check the project references and clean "bin" directory.
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.
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.
I have searched google for this and could not find the solution to the problem.
My Website references DAL (custom dll) which references Enterprise Library Data Access Components.
I have added the Enterprise Library from the NuGet Package Manager and when I try to build the Website this compilation error pops up:
Error 44 Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Common' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference
I have tried setting the Copy Local = True in the DAL for the Enterprise Library dlls and the dlls are transferred to the Bin directory of the website along with DAL dll, but still the error pops up.
Can anyone guide me on this....
The problem is that the DLL that you are using and the one that is referenced in your project are different. I'm not sure what the difference in the manifest is, but it could be version and/or public key.
You have a couple of things to try:
Open the properties for the DLL reference in your project and set Version Specific to false.
Remove the reference, delete the DLL from the bin folder, and re-add the reference.
You could also have a different/incorrect version in your GAC. In order to make sure that you are always using a specific, known version create an assemblies folder relative to your project directory, copy the dll to that directory, and add a reference to the DLL in the assemblies directory rather than one in GAC or elsewhere on your machine. This will ensure that only the specific version that you have targeted for the application will be used rather than any version that is updated on your machine at a later time.
NuGet CommonServiceLocator
Install-Package CommonServiceLocator
This dll is likely to be in the GAC on developer machines as part of some windows application installation (my best guesses are Visual Studio or SSMS).
That’s why we are likely to get warnings or errors on the build machine which we try our best to keep the GAC as clean as the production server’s.
To download the file manually, you can go to https://servicelocation.codeplex.com/
To fix the build warnings and errors, you simply need to run a NuGet command to install the CommonServiceLocation package. The package contains only this one dll file. Microsoft has released only 1 version (1.0.0.0) of this file since 2008. The file is fully compatible with all .NET versions and all Unity versions.
I was able to resolve this issue by removing from ALL the Logging references in the app.config file::
, Version=6.0.0.0, Culture=neutral, PublicKeyToken=null
ie:
<section name="loggingConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings,
Microsoft.Practices.EnterpriseLibrary.Logging,
Version=6.0.0.0, Culture=neutral, PublicKeyToken=null"
requirePermission="true" />
Becomes:
<section name="loggingConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings,
Microsoft.Practices.EnterpriseLibrary.Logging"
requirePermission="true" />
This is not ideal, but it does work...
The Enterprise Library Configuration Tool, sets the values back, so you need to watch for that. I know there is a way to tell the config file to accept these mis-matched settings -- but I I am not sure how.
Setting the PublicKeyToken values for each of the EnterpriseLibrary references in Web.Config fixed it for me.
Remove the reference, delete the DLL from the bin folder and VS, and re-add the reference.