I have a Visual Studio solution which is running fine. I have copied a few projects from this and put in a new solution. When i try to run in one of the calls it gives me an error that a dll is missing.
I confirmed the existence of the dll in the project which is holding the reference to this other project, on further inspection, i observed the version number of the dll in the error message is not matching the version number of the dll that i had copied.
What might have gone wrong in my copy the project?
Please let me know if my question is at very high level? I will put in required details as you may need.
i understand error.refer the follwing link and go through the comments ,u will definetly got the answer.
.Net picking wrong referenced assembly version
OK, i showed this error to my technical lead and here was his finding -
it was because of another project which was being referenced in my main project. This another project was having a reference of this dll too. This another project was of the version number which i was getting an error of.
My TL told me that since this another project was compiling of different version number, it was expecting my dll to be also of the same version.
Over here, i have used the term another project for convenience of understanding only. It is not "another project" but another dll instead which is internally referring to the dll which i was also using in my main project. It seemed that these dlls should both have been of same version for running correctly.
I found and copied this dll from my colleagues machine and referred it in my main project and got through with this problem.
To identify this dll also -
We ran the old code and new code and with help of ProcMon my TL concluded the version conflict of this another dll
Related
This error occurs immediately after building the project, I've tried changing the dot net framework from 4.6 to a lesser version it still does the same thing.
Reinstalling visual studio 2015 doesn't still correct this issue.
Did you check your build path under project > properties> build > output ?
Ok, you don't provide a lot of details so I am going to make some assumptions as I have seen this issue before and it can be a bit tricky.
It sounds to me like you have other issues.
You probably have another project being referenced by your main project. This second project is not building. That's what you need to focus on. Try and build only that project first, when that succeeds you can build your main project and this issue won't happen.
The way things work is like this.
You try to build your main project.
The compiler goes to the referenced projects and tries to build those first, if that succeeds then the dlls generated are copied over to the bin folder of the main project.
If my assumptions are incorrect then please edit your question and add all the details you can so we can actually help you.
I'm getting an error in my project when published caused by a dll that is being changed.
I noticed that, once my project was published and installed a certain dll was half the size of the original, when I replaced it the bug was fixed.
So now my question is, how to prevent visual studio from changing the dll when publishing?
Debug:
Publish:
Thank you for looking
So I figured it out, the issue was that the referenced dll was the one actually being published. So the referenced one was the one with the smaller size.
I have no idea why it debugged with the other one.
Anyway, I changed the referenced one with the bigger dll and now it's published with the correct DLL.
Thank you everyone.
I'm working on a Web Application in Visual Studio 2012 using HtmlAgilityPack. My project references the 1.4.0.0 version of the dll in the application's bin folder. Previously it used 1.3.0.0
The application works, but about once a day the dll in the bin folder is overwritten replacing version 1.4.0.0 with 1.3.0.0. I've already checked the GAC and deleted my ASP.NET temp folders the first time this happened. Does anyone know what's going on here?
You need also delete the 1.3.0.0 dll from you solution's reference list from Solution Explorer.
The older .dll is apparently being referenced from somewhere within your solution. I would open the project file(s) in an editor and look for any references to older versions there.
If none are found, my guess would be that some other library or component you are relying on is referencing the old version of the .dll (are you using any third party libraries?). If you don't have the source for these, then perhaps you can decompile them using JustDecompile or some similar tool. Then you can at least check the references within the dll's your using, and confirm or rule it out as the source of your problem (no pun intented ^^).
Oh, and one more thing - maybe obvious, but have you set Specific version = true for the reference?
I tried to created a .dll in TFS using VS2010 and use the .dll in a new project.
However, it keep on returning an error message saying the entity point for the method cannot be found.
To see if there is some error in the code of the class library, I created another class library project but not in TFS this time. This totally works well. This one can be referenced by C# using "using".
However, the one created in TFS cannot be referenced.
I would like to ask, what's the difference between these two .dll I created and what can I do so that I can successfully reference the .dll I created in TFS.
Many thanks!
Are you sure the error didn't say "Entry Point Not Found"? I have seen this many times when a project is set to build in x86 format when it should be building in x64 or AnyCPU. Right-click on the solution and go to Properties. Click Configuration Properties. Find your project and look at the Platform column. AnyCPU is usually your safest bet.
I currently have one solution that references ten .dll files. Those .dll files in turn all reference a shared .dll file.
Today I started getting an error while debugging that stated, "The source file is different from when the module was built error.", immediately following a recompile of the shared .dll.
I tried all of the usual. I deleted bin and object folders. I recompiled. I closed all instances of Visual Studio and restarted after they were all closed. I restarted my machine. Nothing fixed seemed to fix it.
I'm guessing one of your 10 DLLs references a different copy of the shared DLL, and not the one you compiled.
Since you have all the sources, put all the projects in the same solution, and have the DLLs reference the shared DLL's project. This will solve your problem.
It has happened to me too. Once I fixed it by recompiling project-by-project from ground up (in the same order that VS does).
Another time this didn't help. I can't remember what I did then.
I believe it is a bug in VS.
I notice you are running VS2008. The problem might go away with an upgrade (the supposed bug might have been fixed). VS2010 is also nicer to work with than VS2008 so it could be areason of its own to stay current. Why not download an evaluation VS11 and try it there.
Move all projects to one solution, reference them in a simple and correct way. Compile. Now you have the right DLLs everywhere and can go back to your more diverse solution(s).
You can also try to use MSBuild. It is easy since you already have the projects in VS. Once it is build by MSBuild (which VS uses itself) it should probably compile in VS again.
Finally you can try to build with nAnt. Once it compiles you can probably compile in VS again.
Good luck. I've been there. It sucks.
I suppose you referencing in your project directly to some DLL, and not a project. Which means if you even cleanup and rebuild, the same dll will be used like a reference.
Very often this is a problem, so I suggesting you check your references.
[edit] Assumed this was asp.net, disregard. [/edit]
Have you deleted everything your temporary .NET folders?
Either in:
C:\Windows\Microsoft.NET\Framework[Your Version]\Temporary ASP.NET Files
or
C:\Windows\Microsoft.NET\Framework64[Your Version]\Temporary ASP.NET Files
When comparing last-modified dates of the shared .dll across output folders of all of the solutions with the file that was stored in the output folder of the primary solution, I noticed that they were not the same as the file that I had just built.
This didn't make sense to me, so I simply copied the new files into the output folder. This did NOT solve the problem. On subsequent builds, the old version was again placed into the output folder, immediately causing the error while debugging...
During compilation, an older version was being pulled along with one of the other referenced .dlls. There is obviously some sort of check that is made with the names of files pulled in so that only 1 file is used, but no check is made for latest version number.
I was able to actually solve the problem by creating a reference to the shared .dll from the primary solution. Direct references are obviously (or perhaps hopefully) pulled in before files that are referenced by references (and are already copied into the same output folder as those referenced .dlls), so the latest file was successfully pulled in first.
If clarity is needed, let me know!
I rarely respond to posts since I am generally too busy, but I just spent a ton of time on this same exact problem. I am running VS 2008 in Windows 7. I had set the my Visual Studio to run in XP Compatibility Mode to fix some issues I had with a different project and forgot to reset it to NOT run in compatibility mode.
Once I removed the Run In compatibility MODE (In Windows Explorer on the DevEnv.exe) my problem with the source being out of sync with the debug information went away.
Hopefully this might help someone in the future with the same problem.