I have a scenario where i have library say for example : SomeLibrary.dll which references to System.Net.Http and System.Net.Http.Formatting just an example with Copy Local flag true, and that assembly is actually consuming some types of these two dlls.
Then i create a new Project and i add reference to SomeLibrary.dll with Copy Local flag true, when use methods of this dll which are internally using the above 2 libraries, the runtime error comes saying:
Could not load file or assembly 'System.Net.Http.Formatting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
What i was expecting was it should have dependent assemblies on which SomeLibrary.dll depends should also be in the bin folder copied, which is not happening.
Am i missing something here?
UPDATE:
For your information, i am able to make it work by adding reference seperateely to those 2 dlls but wondering why i need to add seperately if i have reference to SomeLibrary.dll which is dependent on those 2 dlls.
I just had a very similar sounding problem, where I had assembly A depending on assembly B, and B depended on System.Net.Http.Formatting.dll. For some reason on my build server it wasn't copying System.Net.Http.Formatting.dll so it was missing in the final package it created (though in my case it wasn't in either projects' output folder). It worked fine locally on my development machine and I verified the assembly existing in the same place on the build server as it did on my machine (C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 4\Assemblies).
I worked-around the problem with this answer to the related question, which was to switch to using the Microsoft.AspNet.WebApi.Client NuGet package to pull in that assembly explicitly. Unfortunately I'm still not sure what the problem was.
Related
My web project use .NET Framework 4.7.2 and use some references like
System.IO
System.Net
System.Net.Http
System.Net.Http.Formatting
My project works perfectly in local.
However, when I publish my web project on a target directory (for online), and look what it contains in /bin/ :
System.IO is missing
System.Net is present
System.Net.Http is missing
System.Net.Http.Formattingis present
Therefore, when I use my website, I get the obvious error Could not load file or assembly 'System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
All references have Copy Local = True in Properties but some dll are always ignored. If i copy the dlls from local directory to target directory i get the error Server Error in '/' Application. Cannot load a reference assembly for execution. Exception Details: System.BadImageFormatException: Cannot load a reference assembly for execution. Exactly the same problem as this one.
However the delete/rebuild solution, or adding compilation options solution, doesn't work for me
What do I need to do to get these missing dlls to the destination folder?
Go to Solution Explorer on VS, open references tree, right click on the library(dll) and select properties on the menu. On properties box Copy Local should be True
I added a project to my web site solution. Everything built fine locally and on the build server.
I added a line in web code to call a method in the new project. Everything built and worked fine locally, but it broke the build on the build server.
I got a pile of errors going something like this:
warning MSB3268: The primary reference "C:...\ProjectName.dll" could not be resolved because it has an indirect dependency on the framework assembly "Assembly.Name (e.g. System.Runtime)", Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.5". To resolve this problem, either remove the reference "C:...\ProjectName.dll" or retarget your application to a framework version which contains "System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
After all the warnings, the build failed with an error indicating the namespace ProjectName could not be found. Makes sense considering the project's dependencies couldn't be resolved.
At first I wondered if there was an issue with targeting the wrong framework. But there was a mix of 4.0 and 4.5 projects referenced by the 4.5 website. This was the first one that had failed.
The only difference between this and the other projects was that it referenced third-party DLLs. So apparently their dependencies are the ones that couldn't be resolved.
This post held the key: http://devsilos.blogspot.com/2014/10/msb3268-while-targeting-aspnet-web-site.html
The author suggests:
aspnet_compiler for some reason does not take into account the .dll-s that reside under the Facade directory of 4.5 assemblies (C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5\Facades).
It looks only under
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5
My extrapolation on that idea is that maybe the compiler doesn't take into account DDLs in the Facades directory if they're referenced by a third-party DLL rather than directly from your project.
The solution, as suggested by the author, was to find the DLLs matching assemblies mentioned in the MSB3268 warnings and copy them from Facades to its parent directory.
I think my problem/solution differed from the blog's in that it had nothing to do with the .NET Framework version targeted. It had only to do with whether the build server's compiler looked in the right places to resolve third-party DLLs' dependencies.
The problem caused about ten hours of frustration. I hope this helps someone else avoid that!
I downloaded source code for pdfiumviewer from git hub. I made changes to one of the projects in that solution.Then I added that project to my application and added reference of that project to one my application's project.I had to uncheck the Signing option for the PDfiumViewer project, as some of the dll in that project are unsigned.I am able to build the application successfully.But at run time when I create an object of one of the class of PDfiumviewer project.It gives me the following error:
Could not load file or assembly 'PdfiumViewer, Version=2.11.0.0,
Culture=neutral, PublicKeyToken=null' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040)
The version number of the assembly is correct.So, why am I getting this error?
The problem was that I had added reference of old unmodifed PdfiumViewer dll to another project.Hence, there was conflict between the two dlls (old and customized) at runtime.I removed the old dll reference and it worked.
Ive also encountered this issue, my scenario was thou that I had to add a reference from another solution into my project removing the reference was not an option - what worked for me was reinstall SQLclient from nuget package managerer on both solution. Hopes it helo someone else
The issue here is that you have a library that references v2.11.0.0 of the Pdfium library. This library could be an assembly that you built earlier, or another assembly that came from Pdfium that references this version of the library. When you built your version of the library you probably didn't use this same version number, and it wouldn't have been strong named correctly. To fix this, you can add an assembly binding redirect in your applications configuration file to redirect the offending library to your custom built one.
I wrote a program to fix this issue automatically: https://github.com/BackTrak/DependencyFixup/releases/tag/1.0.0.0
I know this question is old, but hopefully this helps out others!
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.
I have two projects. Project A is a web project and project B is a Data Access Library. Project B has references to another Project (Project C), as well as some third party dlls that are referenced through files in a directory call "Library". If I reference Project B as a project reference, everything works. If, instead I reference the dlls that are output into the bin/debug folder of Project B, everything builds, but I get the following error we the built in development web server tries to show the default page.
[BadImageFormatException: Could not load file or assembly 'my_dal.data, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.]
I'm running Windows 7 64 bit Operating System, so it would seem I have a 32/64 bit problem, but I can't see how the build process is working with one reference and not the other.
That's because the project knows about it's own dependencies. A DLL doesnt provide information on dependent binaries that visual studio also needs to provide.
Either way, you should reference your project as a project not a binary, because then when you make changes to it, they automatically update the DLL on build.
The reason behind why referencing the files in bin/debug folder fails is because those files gets wiped out when you rebuild/clean the solution. The best way to reference a project in another project is to add it as a project reference and not through binary files.
The error you are getting there indicates you are trying to either
A) Load an assembly built for 64 bit and your on 32 bit
B) Load an assembly built for 32 bit and your on 64 bit
You can fix this error by changing your project to build for "Any CPU"