Click here to Skip to main content
15,919,422 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
So I have a solution in Visual Studio 2005 Pro (C#) with a handful of projects in it. Most of them are Class Library DLLs using COM to extend an existing application (ArcGIS). But since there's a lot of things that all of these projects do the same, I have a shared library DLL included as one of the projects. (And one of the other application DLLs, shares some of it's stuff with some of the others as well.) VS is smart enough to know that all of the other projects are dependent on the shared project and builds things in the correct order. If I do a clean solution first and then build, it also does things in the correct order.

But, it doesn't handle things correctly if you modify the shared library and re-build. It appears to rebuild the shared library first since it's first in build order as it should be. But it doesn't clean the other projects first so when those build, it first tries to unregister the DLL and fails since the shared library that DLL uses doesn't exist with the version it expects. "Cannot unregister assembly <application dll>. Could not load file or assembly '<shared dll>, Version X.x.x, etc..' or one of its dependencies. The system cannot find the file specified." If I rebuild again it compiles fine. So it's not a major problem. But it gets annoying having to do a clean before each build or build 2 sometimes 3 times before it gets through these errors and actually builds.

When I make a change to the shared library, I would expect it to mark the dependent projects as also needing to be rebuilt and clean them first, rebuild the shared library, then build the dependents. It seems to just rebuild each project one at a time starting with the shared. I would probably be fine if I could tell it to always clean on any build. It would take a little longer to build but at least I wouldn't get bothered with this all the time. Anyone have any suggestions on how to deal with this? Thanks.

Can't you set a pre-build step for everything (to unregister the com objects), compile everything, and then a post-build step that re-registers the com objects?
Share this answer
Ah crap, I had forgotten that I had already implemented some pre/post build steps which actually delete all instances of the shared library. Which then cause my errors where it can't find the shared library when unregistering. So I created my own problem. The reason I was deleting the shared library in the pre/post build steps was because the shared library was used in different projects/solutions. If I built one but not the other, the one that happened to load first would load it's version of the shared library which would then cause the other project to not work. By deleting the shared libraries, I was sure to not have this problem. Now that I've moved most of these projects under one solution, Visual studio can handle the rebuild so I shouldn't have this problem anymore. Thanks for getting me pointed in the right direction.
Share this answer
#realJSOP 26-Aug-10 6:02am    
No problem. I hate forehead slappers like that. :)

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900