.Net Assembly Hell is what we've been calling it here.  MS will never
learn.  Yes, we have gotten it to work by deleting all existing references
in our projects and re-adding them.  This is such a nightmare!  We have
several dozen projects.  The problem would not be so nightmarish if we
could some how write a utility to tell all of the projects to resynch with
the current version.  As I said before, we only have EXACTLY ONE copy of
the assembly in the entire system.  I guess there is no way to fix this.
This is much worst than DLL hell.  With DLL hell, users had the problems
and developers can figure out how to quickly fix it on their machine.
With .Net assembly hell, you have no clue, and it shows up every time.

With the copy local issues, I suspect it only helps with a separate issue
that display similar symptoms.  The one I am currently seeing refuses to
fix itself after switching copy local to false and clicking the resynch
button.

It is ashame.  They wanted to fix DLL hell and copy some of the ideas from
Java, but they introduced a more hellish problem by trying to
differentiate from the way Java does packages.

You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.

Reply via email to