I found posts mentioning issues with DEVPATH and webapps and I think MVC falls under this same band-wagon.
On my local PC; in one instance I need to be able to design and test our library of dlls; on another, I need to use these dlls, in various websites. Due to the number of sites we handle, we are looking at storing the dlls in the GAC in an attempt to avoid duplication.
When I want to work on the library I need to remove all the dlls from the GAC and then re-install them again once I have finished my development.
I have everything set as defined in various sources to make DEVPATH work, but it isnt working for me in my MVC project.
Is it possible to have dlls installed in the GAC, but run an MVC project that uses the DEVPATH copy.
I'm not having a lot of luck finding anything on the subject, but I am hoping it is possible.
Finally got a work around, it was quite obvious now I have done it.
It is a bit of work, but it does mean you can debug a website.
Also, it isn't using DEVPATH still, but it works so I am happy.
The main assumption I made was that the GAC always wins, even if you physically copy the dll to the bin the GAC will find the file first and use that reference.
So, the way I have found to work with local files (especially when I want to be debugging a website), is to change the assembly version number of the projects I reference to a new number. As this version doesn’t exist in the GAC, the Visual Studio webserver(cassini?) and iis web servers will use the local dlls. So any breakpoints I had added to my services etc. will then be picked up.
Related
I am very new to the .NET framework, and have been stuck on this issue for a week now.
I've been given a C# codebase, that is composed of several sub-projects which make use of DLLs compiled in C++. Each of these projects are inter-related, as they reference each other (non-circular).
If I create a basic Windows Forms Application, I can call functions from these DLLs no problem, by adding a reference to one of these sub-projects. However, if I create a very basic ASP.NET web app (which builds and runs fine on its own), it will break as soon as I add a reference to the sub-project I need.
By breaking, I mean I am given this error:
Could not load file or assembly 'XXXXX.DLL' or one of its
dependencies. The specified module could not be found.
I have done a lot of reading on this, since it seems to be a fairly common error, but none of the attempted solutions have worked.
To generalize, my main question is: Given two projects (one a windows form C# application, and the other an ASP.NET web application), both located in the same directory referencing the same project/DLLS, why does the web application struggle in locating the proper DLLs and/or dependencies?
Thanks in advance!
In the .NET application, have you tried compiling the DLL's and copying them directly into your /bin directory? That way you're eliminating the dependency and any reference issues VS may be choking on.
Then be sure to remove the references from your project so it's only using what it finds directly in the /bin directory. See if that works for you.
Once you're sure the issue is truly the references vs the DLL's themselves, and you project builds completely, try adding the references back in....be sure to do a clean of the project, then a rebuild.
If that still doesn't work, make sure both projects are not in the same solution. I had this issue not too long ago and it only seemed to work when I removed the other projects from the solution, opened another instance of VS2015 and then I was able to get everything working.
I know, I know....not really an answer if that ends up working, but when it comes to Microsoft's products sometimes we need to get a little creative. Let me know if this helps.
This is so frustrating. For some reason I have added a dependency Microsoft.VisualStudio.Text.Logic into my application so when I deploy it, it gives me the typical "Unable to install or run the application. The application requires that assembly XXX be installed in the Global Assmebly Cache (GAC) first". No big deal.
So I went to the application files section and it doesn't show up. Then I checked my references and nothing shows up. As a last ditch effort I checked under the "Add References" panel and it's not there. For some reason my Build Server has it, but all my end users as well as my development machine do not. Is there anywhere that I can check as to what dependencies are required and remove them? I cant find any code in my application that would required this DLL.
I guess this question can be generalized as this: "What is the best way to find dependencies for a project to prevent new ones from being created"?
So i found a solution that probably doesnt directly solve it for most people, but it is something good to keep in mind. What i didnt realize was that the Visual Studio versions were different and for some reason the one on the build server was adding a bunch of dependencies (like 15). I solved the issue by updating the server to contain the same visual studio version as my development machine.
i have an issue with the old setup projects in VS2010. please don't blame me for using that. it's a company decision which cannot be changed. poor enough i HAVE to deal with it.
i think it's quite usual what we got: a solution with some projects. the projects reference assemblies. some of them are 3rd party components. they are ALL referenced to/from the SAME individual folder (NOT the GAC or something like C:\Programs...). we just don't reference the installed versions. we want to keep them all in one place.
here comes the point... the project itself points to the folder we want. building and running is fine.
when i examine the setup project, SOME of the 3rd party assemblies are taken from our specific folder, others are taken from C:\Programs...
i just don't know why. i cannot influence this as it seems. even manually editing the .vdproj file ( were "GAC:FALSE" can be set) doesn't help! we need to reference the specific *.dlls in our folder.
has anyone an idea on this? i haven't found something so far...
cheers!
jens
This is how VS behaves. Even though you told him to search for your 3rd party dlls in your own folder, if it finds the same dll in GAC, it will reference it from there. On computers that do not have the dll in the GAC, it will reference it from your folder. In other words, if the computer you deploy your application has all the 3rd party assemblies in the folder that you referenced them from, and the folder exists on the target machine, the application will not crash, even if the dlls are not in the destination you see on your own machine, and will use the assemblies from the folder.
Maybe somebody fiddled with the default reference paths in Visual Studio. If you look at this article, about half-way through it explains the registry keys that are used to locate referenced assemblies:
http://msdn.microsoft.com/en-us/library/wkze6zky(v=vs.100).aspx
I think that the VS search mechanism will go through this list at build time, and you may end up with a rather strange combination, especially if some assemblies have dependencies on others and the assembly versions are different. So if you start with a certain assembly that requires others with a particular version it will chase that list of directories until it finds them.
I don't believe it is correct that VS will get assemblies from the GAC by default for reference purposes. The .NET runtime will do this when you run the program, but at dev time all the MS assemblies, for example, are referenced from the SDK install, not from the GAC. The GAC is a repository for running programs that require those assemblies, not a reference for dev builds.
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.
We are using TFS and VS 2010.
I have been working on a project that is using TFS as source control.
I have quite a few dlls that I have downloaded (such as log4net) and referenced in my project.
When a new programmer connected to TFS and got my project out of source control, it failed to build as it said it was missing all these referenced dlls.
What did I do wrong here? How can I include those referenced DLLs in source control.
Do I need to add all these dlls to my project before referencing them? when I referenced them, I just browsed to where they were on my file system.
I've found the best practice for 3rd party DLLs is to create a "Library" folder in your sln/proj file structure and copy all the necessary DLLs into this local folder for reference. You'll also want to make sure these DLLs are checked into source control. This way, everyone who works on the project gets the exact same versions of all DLLs, and the reference paths are exactly the same.
Referencing 3rd party libs in a arbitrary download or install location will be problematic, because it will require all developers to maintain the same download structure for all DLLs. Also, if everyone references DLLs outside of the project structure, it's harder to guarantee that everyone's on the same version.
The other option would be to have everyone install the DLLs into the GAC, but that can be a real pain too, especially with version management and deployment.
I created a "ThirdPartyDLL" folder in my project folder in which I copied all the extra DLLs into it. I then went into source explorer and added those DLLs into the team foundation server so I could be sure I'm using the correct versions of the DLLS for specific versions of my application (and so everyone else is on the exact same page as I am).
View - other windows - Source coontrol explorer
Right click project folder - add items to folder
You won't be able to select a specific folder with DLLs in it, but instead you can select the individual DLL files within the folder. You will then see the "ThirdPartyDLL" folder appear in that window.
Once this is done, those dlls are in the team foundation source control. Whenever a dev checks in, they will get the most current version of the DLLs.
Don't forget to remove the old references in your app and change them to your thirdpartydll folder.
I used to copy the DLLs into the bin folder but the issue I ran into was when the DLLs got upgraded. Initially when my project was small it wasn't a big deal. Now that I have multiple DLLs and applications that I created it became very difficult to maintain consistent versions of DLLs outside my project. My best example is the licensing dll I purchased. When this got upgraded all applications and libraries needed to be on the same version. If I forgot one then I had weird issues or the application just stopped working. Now that I have everything in one folder, I make the change once and everything is upgraded.
Hope this helps.
Andy's suggestion is a good one and I've used that in the past. At my current job, we have a "reference" folder on a network share for all of us to build from. We have a very fast network here, though and all developers are in a single office. This solution won't work as well if you have a lot of remote developers or a slow network.
I've tried various methods for dealing with this and have settled on dropping required dll's in the bin folder and making sure they are included in the project for source control. I've heard people say this might not be a good idea but nobody has provided good reasoning for it and it's worked well for me.
My second choice would be to carve out some space on a network share and organize the various 3rd party dll's there. You can put your files in folders with verion numbers to keep things straight and everyone should have access to everything they need, so long as everyone uses the normal network paths as a reference.
Adding a seperate folder within the project is also workable but seems messy, since you end up with extra files that you don't want included in your release.