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.
Related
Im having an issue when upgrading Telerik references in a VS2019 C# project. Current version is 9.0.* and upgrade version is 16.1.*.
In the .csproj with the current version the reference is defined this way
**<Reference Include="Telerik.Reporting">
<HintPath>..\dll\External\Telerik.Reporting.dll</HintPath>
<SpecificVersion>False</SpecificVersion>**
If i update the reference from add reference->assemblies->extensions the .csproj code looks like this, and its ok:
**<Reference Include="Telerik.Reporting, Version=16.1.22.622, Culture=neutral, PublicKeyToken=a9d7983dfcc261be, processorArchitecture=MSIL" />**
But here comes the issue. I have to do a local copy inside my project of the telerik.reporting.dll. So I pick the C:\Program Files (x86)\Progress\Telerik Reporting R2 2022\Bin\Telerik.Reporting.dll and copy it inside my C:\GIT\MySolution\dll\external folder.
Once i have the file copied i update the reference from add reference->browse. And then the .csproj looks like this
**<Reference Include="Telerik.Reporting, Version=9.0.15.225, Culture=neutral, PublicKeyToken=a9d7983dfcc261be, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\dll\External\Telerik.Reporting.dll</HintPath>
</Reference>**
The version of the telerik.reporting.dll in my external folder is 16.1.* but somehow the .csproj code now shows the 9.0.* and dont now why.
Thanks for your help.
I'm on V16.4.1 and the project is targeting .NET Framework 4.7.1
I have a solution with multiple projects which all run fine except one which gives the above error. I searched the project and can't find any using references to it and just in case, I added the dll to my references. I searched the entire solution in case I was referencing it through another project but there is no reference to it anywhere
I tried deleting bin & obj folders. Cleaned and rebuilt the project but I get the same error every time.
Edit: The project can build, this only happens when I try to debug it
bin\roslyn\csc.exe is throwing the exception
Could not load file or assembly 'System.Collections.Immutable,
Version=1.2.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or
one of its dependencies. The system cannot find the file specified.
I use
Visual Studio Professional 2019 ver 16.7.6 / Preview: 16.8.0 Preview 4
and I found the same problem with many 'old' project using .net framework when I compile them from scratch (i.e. deleting bin/obj directories).
The compiler does not recognize that the runtime needs this package, and the solution is to copy in the bin directory the requested version (1.2.3.0 in this case) of DLL System.Collections.Immutable.dll
You can download it adding this line to packages.config file:
<package id="System.Collections.Immutable" version="1.2.3.0" targetFramework="net471" />
but still need to manually copy the .dll in bin directory.
Or add the package with Nuget.
Stefano's answer worked for me
this file is a dependency from my firebase dll, tough i didn't need to modify packages.config because the file exists in my bin folder
I just included System.Collections.Immutable.dll file in in VS project
then changed in file properties > advanced > copy output > copy always
thanks!
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
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.
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.