I have an c# application with two libraries ( moon-apns, tweetsharp ) .. Each library has a reference for newtonsoft.json.dll but different versions ... My app build successfully but one library works fine and the other one throws an exception ( can't find the dll file ).
I think that when i build only one version goes to the bin folder, but i don't know what to do.
Thanks in advance.
You can force both libraries to reference the same version by using Assembly Binding Redirects in your app.config or web.config. Obviously this only works as long as the library versions are compatible.
Since you stated you have access to the source of the two libraries:
In both projects, set the reference to newtonsoft to not required Specific Version. Rebuild those projects.
Now, when you build your main project, the two libraries should be ok with the same version of the newtonsoft DLL as long as there is no compatibility issues
Related
I have two packages installed, and both contain the same precompiled assembly file. This causes an error in Unity and I have no idea how to resolve this issue. Both files are necessary for the packages to function, so deleting them is not in question. How should I resolve this error?
I've forked one of the packages and attempted to rename the DLL file and re-add everything into the Assembly References section of the Assembly Definition Import file - however, one version of the DLL file is 3.8.0.0 while the other is 3.15.0.0.
The DLL file is Google.Protobuf.DLL
Many thanks.
Welcome to the Dependency Hell =)
If we are talking about how to resolve this - don't think there is some easy solution =/ I can suggest several options but both are not perfect at all.
Let's say that package A requires protobuf v3.8.0.0 and package B requires protobuf v 3.15.0.0.
First of all, you can try to check older releases of package B to try to find one with protobuf v3.8 dependency instead of v3.15. Or, vice versa, try to find newer release of package A with v3.15 dependency instead of v3.8. If you are lucky enough - it can help.
If package A or package B has source code available (for example, it is a git repo), you can try to adapt it to another version of the protobuf library manually (create your custom version or even make a pull request to the package repo). But this variant can cause future problems with package updates as you will have to support your custom changes.
I'm using a mysql .NET Connector library (Mysql.Data) in my project. As far as I understand it, I only need to use the mysqldata.dll which is in the assemblies folder after the connector is installed. I'm going to be using the program on a computer that has .NET 2.0 but doesn't have the connector.
How do I add the .dll file to a project such that the dll is used internally - I hope that makes sense. If the program calls out to .NET to find it, (as it does) - the whole thing fails and errors out.
In Solution Explorer, under your project, expand References, select the MySql.Data assembly, view the Properties for the assembly, and change Copy Local to True. Now when you compile the project, MySql.Data.dll will be output to the bin directory.
(You will not embed one assembly into another. Instead, you deploy the MySql.Data.dll along with everything else in your build output which is required. This is simply known as adding a reference ... I don't think you really wanted to embed it.)
Strange situation.
inside a solution I have several projects. One of them is called Common, other is a web project (not a web application) called Internal.
Internal has a reference to Common, so every time I build the application, the common DLL is copied to the bin folder on the Internal website.
If I change a line of code on a class on the Common project and rebuilt it the DLL isn't updated on the Internal bin folder (even If I rebuild the internal) resulting in running the OLD code of the Common (If I have a breakpoint on Common, it show a warning saying that the code differs from the original and wont run). The only way I manage to solve it is manually deleting the Common DLL on Internal and then rebuilding.
My question is, how can I avoid it? How can the dll always be the same version on Internal?
Thanks
As requested by OP:
Try removing the reference and adding again though the 'Projects' option on the 'Add Reference' dialog. This should set up the DLL to be refreshed when it is rebuilt.
One of possible straightforward solutions could be the simple use of PostBuildEvent where you put batch-code that on successful build always copies files you need.
The bad about this that you increase your compilation time.
If you are using third party dll which has been developed been higher version VS2013/vs2015 (i.e .NEt 4.5 , 4.6 , 4.6.2) then it will not work properly in VS2010
Answer: Convert your project to VS2015 to resolve issue or install .NET 4.6.2 and user VS2013 and change framework to latest
Somehow I've been lucky and never had to deal with this problem, even though I think it's a common one:
I've got a web project, let's call it SomeProject. SomeProject has a reference to a 3rd party library, let's call it SomeThirdParty, version 1.0. SomeProject also has a reference to a home-grown class library, let's call it SomeLibrary. SomeLibrary also has a reference to SomeThirdParty, but a different version (let's say 2.0).
Version 1.0 and 2.0 of SomeThirdParty share most of the same signatures, but are different implementations. I need SomeProject to use the 1.0 implementation, and SomeLibrary to use the 2.0 implementation if possible.
I compile SomeProject using its reference to log4net. The DLL that ends up in the bin directory is the one that SomeProject references. At runtime, when code from SomeLibrary runs, it attempts to execute the code from version 2.0 of SomeThirdParty, and of course fails, throwing a FileLoadException: Could not load file or assembly 'SomeThirdParty, Version=2.0.0.0, Culture=[etc.]' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
Obviously I could upgrade SomeProject to the newer DLL or downgrade SomeLibrary to the older DLL, but it wouldn't be ideal for many reasons.
I think the right answer involves installing SomeThirdParty in the GAC, but I'm not sure exactly how I'd go about doing this, and how it would affect other developers and servers.
Any suggestions you may have are appreciated.
Thanks for the help.
Putting both versions of SomeThirdParty into GAC should do what you want. Use gacutil utility or Start->Run->assembly then drag-n-drop.
From my answer earlier: https://stackoverflow.com/a/19576769/2367343
I ran into this yesterday for visual studio web developer using Oracle.DataAccess.dll.
My solution,
right click your project (*.csproj) and edit it.
Right underneath:
<PropertyGroup>
Place
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
Then rebuild your solution. You must separate the two version dlls into two different directories in your project when including them (required).
I did
ora11 >> Oracle.DataAccess.dll (Version 11)
ora9 >> Oracle.DataAccess.dll (Version 9)
Doing this allows your IDE to use both versions of DLLs.
When I add a reference to my dll in Visual Studio project, I am able to use it, but when I compile my code or try to run it, I get an are you missing a using directive or an assembly reference?_ Error. I am able to confirm that I have the right using statement for my namespace and I am able to confirm that the dll is correctly loaded.
Anyone have any idea what I may not have right in this?
Go to project settings and make sure that you are not compiling the project for a .net version that includes the text "client profile".
I had just had an issue precisely like this, even if this is an old question thought I would add my 2c on what fixed it as none of the other answers helped:
For whatever reason, when I built the solution top to bottom a certain dll was not getting updated and output that held changed code. So while my solution had no visible errors, when you attempted to build, it was still referencing the old dll and started complaining.
It was simply a case of directly re-building the offending project and after that it picked up the latest dll and built happily.
This seemed to be a freak accident as no configuration had changed between when it worked / when it didn't.
Sometimes, JUST REBUILD THE SOLUTION.
The location of the DLL is important.
If you add a reference on your local machine to a DLL that is outside of your Visual Studio solution, it isn't necessarily copied into your solution files (depends on the type of solution/project).
If this is your problem, then you need to either put the DLL in the same path on the other machine, or copy it into your solution so it gets deployed along with the solution files, and change the reference.
You can also handle this with build instructions, but that might be beyond your aspirations at the moment.
Most likely your dll is referencing another dll that the client project is not referencing and your dll code is exposing a type or an interface from the 3rd dll to the client code.
If you post the exaCt message, we'll be able to help better.
Are you using .net 4.0?
If yes, this dll is probably not compatible with .net 4.0
In my case, the main project (WinForm) was configured Framework Target: FW 4.0 "client profile". I change to FW 4.0 and work perfect!!.
At first time i was looking in the referenced projects and they were ok, but de main project doesn't. I hope this help. Thank you.
In my case this compilation error has gone after adding the reference to Microsoft BCL Build Components via "Manage NuGet packages" context menu on problem project.
Before: I had project Main (console application) referencing project A (class library).
Project A had dependency on Microsoft BCL Build Components.
After: I started refactoring where I picked out several classes to the separate project New. It also depended on A. But the compilation error occurred on project New as if there was no reference New -> A (although Visual Studio didn't highlight allegedly not found interfaces and classes listed in the error list of compilation).
So I checked project A's dependencies and found there Microsoft BCL Build Components.
After adding it to New's dependencies everything worked fine.
The most interesting thing is that Main did not contain this dependency and it didn't need it.
Hope this helps.
You just Have to check your namespace of that class file again...it will work