DLL hell

  • Thread starter Thread starter Toby Mathews
  • Start date Start date
T

Toby Mathews

Hi there,

I have recently started having problems compiling multi-project solutions.
I have a couple of ASP.Net projects that reference a range of .Net DLLs I
have written. For example:

ASP.NET project includes references to - A.DLL, B.DLL, C.DLL, D.DLL etc.

Quite a few of the DLLs include references to my data layer component,
Data.DLL, but my ASP.Net project does NOT. When compiling my solution I
frequently see an error that goes something like,

"The dependency Data.dll version 1.0.20008 cannot be copied to the run
directory because it would conflict with the dependancy Data.dll version
1.0.20010..."

It seems that usually I can get round this by including the projects for
ALL the DLLs that reference Data.DLL, plus the project for Data.DLL itself,
in the solution and making each one refer directly to the Data.DLL project
rather than the compiled DLL. Should this be the case? Just now I had done
exactly this, and switching the compiler from Debug to Release completely
stuffed everything up again.

Can anyone give me guidelines for developing these sort of multi-project
solutions and not seeing the dreaded "The dependency x cannot be copied to
the run directory..." error?

Thanks in advance,

Toby Mathews
 
¤ Hi there,
¤
¤ I have recently started having problems compiling multi-project solutions.
¤ I have a couple of ASP.Net projects that reference a range of .Net DLLs I
¤ have written. For example:
¤
¤ ASP.NET project includes references to - A.DLL, B.DLL, C.DLL, D.DLL etc.
¤
¤ Quite a few of the DLLs include references to my data layer component,
¤ Data.DLL, but my ASP.Net project does NOT. When compiling my solution I
¤ frequently see an error that goes something like,
¤
¤ "The dependency Data.dll version 1.0.20008 cannot be copied to the run
¤ directory because it would conflict with the dependancy Data.dll version
¤ 1.0.20010..."
¤
¤ It seems that usually I can get round this by including the projects for
¤ ALL the DLLs that reference Data.DLL, plus the project for Data.DLL itself,
¤ in the solution and making each one refer directly to the Data.DLL project
¤ rather than the compiled DLL. Should this be the case? Just now I had done
¤ exactly this, and switching the compiler from Debug to Release completely
¤ stuffed everything up again.
¤
¤ Can anyone give me guidelines for developing these sort of multi-project
¤ solutions and not seeing the dreaded "The dependency x cannot be copied to
¤ the run directory..." error?

http://msdn.microsoft.com/library/d...yBecauseItWouldConflictWithDependencyFile.asp

Yes. Strong name your assemblies and register them with the GAC (Global Assembly Cache).


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)
 
Will this cause any problems when deploying my web app. from a test machine
to the live machine?

 
PS I meant to thank you for the advice Paul!

Toby Mathews said:
Will this cause any problems when deploying my web app. from a test machine
to the live machine?
Click to expand...
 
I should also mention, that another variation on this theme is that
sometimes I get the "The dependency Data.DLL cannot be copied..." message
referring to one of the DLLs (say A.DLL), and it can be cured by deleting
the copy of Data.DLL currently residing in the bin directory of that
assembly (i.e. A\bin\Data.DL). Don't know if that helps at all?

 
Hi Toby,

When you make a reference to a DLL, are you making a reference to the DLL in
the /bin directory or the /obj directory?

It matters.

Both work for simple projects. The moment you get into a situation where A
references B references C, this becomes very important.

When you make a reference to a dll in the /bin directory, and the compiler
is searching for all your DLLs to copy to your local directory, it copies
the dlls from the first referenced directory where they exist. This may not
be the one they are referenced from! This is BAD. We want it to copy the
most recently compiled DLL, but it doesn't. That's why you get this
message.

Go check your references. Better yet. drop them all. (at all levels, the
problem is usually buried). Recreate them from the OBJ directory ONLY.

Then, REBUILD everything.

Your problem should go away.

--- Nick

Toby Mathews said:
I should also mention, that another variation on this theme is that
sometimes I get the "The dependency Data.DLL cannot be copied..." message
referring to one of the DLLs (say A.DLL), and it can be cured by deleting
the copy of Data.DLL currently residing in the bin directory of that
assembly (i.e. A\bin\Data.DL). Don't know if that helps at all?
Click to expand...
 
Nick,

Thanks for this, I'm not sure how to make use of it though? I am making
references to projects in my solution, rather than compiled DLLs. VS
indicates that these references are in fact pointing ultimately at the
compiled DLLs in the obj directory, but I'm still seeing these problems.
Sorry if I haven't explained myself very well. To give you an example of
what's happening right now this minute, I have:

- ASP.Net project which references A.DLL, B.DLL, C.DLL and D.DLL, which
are all projects in the same solution as the ASP.Net project.

- A.DLL, B.DLL and C.DLL all reference Data.DLL, which is also a project
in my solution.

- A.DLL also references the projects for B.DLL and C.DLL, and I suspect
that maybe this is where the problem lies. When I try to compile the
solution at the moment I first have to go and delete the most recent copy of
Data.DLL from the bin directory of A.DLL.

Hope that clarifies things a bit?

Toby


Nick Malik said:
Hi Toby,

When you make a reference to a DLL, are you making a reference to the DLL in
the /bin directory or the /obj directory?

It matters.

Both work for simple projects. The moment you get into a situation where A
references B references C, this becomes very important.

When you make a reference to a dll in the /bin directory, and the compiler
is searching for all your DLLs to copy to your local directory, it copies
the dlls from the first referenced directory where they exist. This may not
be the one they are referenced from! This is BAD. We want it to copy the
most recently compiled DLL, but it doesn't. That's why you get this
message.

Go check your references. Better yet. drop them all. (at all levels, the
problem is usually buried). Recreate them from the OBJ directory ONLY.

Then, REBUILD everything.

Your problem should go away.

--- Nick
Click to expand...
 
I may be getting closer - somehow even if my Data.DLL project does not
compile a new copy of the DLL ends up in the bin dir of A.DLL, which makes
me think it's somehow getting hold of an old copy from elsewhere...

Nick Malik said:
Hi Toby,

When you make a reference to a DLL, are you making a reference to the DLL in
the /bin directory or the /obj directory?

It matters.

Both work for simple projects. The moment you get into a situation where A
references B references C, this becomes very important.

When you make a reference to a dll in the /bin directory, and the compiler
is searching for all your DLLs to copy to your local directory, it copies
the dlls from the first referenced directory where they exist. This may not
be the one they are referenced from! This is BAD. We want it to copy the
most recently compiled DLL, but it doesn't. That's why you get this
message.

Go check your references. Better yet. drop them all. (at all levels, the
problem is usually buried). Recreate them from the OBJ directory ONLY.

Then, REBUILD everything.

Your problem should go away.

--- Nick
Click to expand...
 
¤ Will this cause any problems when deploying my web app. from a test machine
¤ to the live machine?
¤

Not that I am aware of. Are you referring to a specific type of problem?


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)
 
Toby,
you may think you are referencing the projects but somewhere, you are not.
I have had this error before (until I learned this lesson).

If B references C and D, and C references E. D is not in your solution. In
D's solution. You are not able to reference D's /obj directory. you
reference D's /bin directory by mistake. In D's project, D references E.

B -> C -> E
B -> D -> E

Now, you compile D. Visual studio copies E to the /bin directory for D.

Now, you open the solution for B. You modify E in some minor way. You
compile the solution.
First VS compiles E.
Then VS compiles C. That copies the new version of E to C's Bin directory.
Then VS compiles B.
In the process, VS looks for the Dll for D, which is referenced in it's
Bin directory. In that same directory is an old copy of E. D copies BOTH
the new version of D and the old version of E to the local bin directory.
VS goes looking for the Dll for C and finds it. It copies C to the local
directory. It also looks as C's dependencies and sees that it nees the new
copy of E. However, it cannot copy the new version of to the /bin
directory, because it just copied the old version of E to the /bin
directory.

The compile fails.

The problem is in the reference to D. Remember, D is not in the solution
(you are not referencing the project, but the DLL itself, and you are
referencing it from D's /bin directory).

Drop the reference to the external dll that references one of the same dlls
that are already in your library. Recreate the reference, this time
pointing to the /obj directory.

This should fix the problem.

That's why I recommend you simply drop every reference and recreate it.

HTH,
--- Nick
 
Nick,

This certainly sounds like what is happening to me, so I'll try doing what
you say. Thanks for your help, much appreciated - I'll let you know how I
get on.

Toby
 
Good grief, I may slowly be getting somewhere. I have found that in one of
my projects, the one that appears most likely to be causing me problems, I
CAN'T change some of the references to other projects to the DLL's in the
obj directories?!

So, in this project, call it MyProj.csproj, (that references the troublesome
Data.DLL) I have references to, say, A.DLL, B.DLL and C.DLL - all of these
also reference Data.DLL. If I change the references for A-C to point at

A\obj\debug\A.DLL
B\obj\debug\B.DLL
C\obj\debug\C.DLL

for example, when I next compile MyProj the references to A and C stay as
they are, but the reference to B changes to

MyProj\bin\debug\B.DLL

I have no idea why this change takes place - can anyone help me?!

Thanks in advance, this problem is driving me mad!

Toby
 
The reference changes? That's a new one on me!

If you open B.DLL, which references Data.Dll, is it referring to
\obj\data.dll ?

if not, then you have the situation that I explained (poorly) above. (sorry
about that... I must have been really tired when I typed that).

--- Nick
 
I'm out of ideas, friend.
All I can say is: look for some place where you have more than one project
or more than one solution, interacting to copy various versions of dlls
around.

None of these is in the GAC is it?

As an experiment, try this:
1) Take a look at your order of dependencies.
2) go to every one of the /bin folders and delete the contents.
3) go to the first in your order of dependencies (data.dll) and compile it.
Now, delete the contents of the /bin directory.
4) go to the next in your order of dependencies. compile it. then delete
the /bin directory.

If you get all the way through to the final app, compiled, then you have
outrun me. On the other hand, if the compile breaks because a dll cannot be
found, then you've found your bad dependency.

--- Nick

Toby Mathews said:
Yup, B.DLL refers to Data\obj\debug\Data.dll.

:-(

Nick Malik said:
The reference changes? That's a new one on me!

If you open B.DLL, which references Data.Dll, is it referring to
\obj\data.dll ?

if not, then you have the situation that I explained (poorly) above. (sorry
about that... I must have been really tired when I typed that).

--- Nick
Click to expand...
one
of
Click to expand...
problems,
I are
not. references
E.
Click to expand...
for
D.
Now, you open the solution for B. You modify E in some minor way. You
compile the solution.
First VS compiles E.
Then VS compiles C. That copies the new version of E to C's Bin
directory.
Then VS compiles B.
In the process, VS looks for the Dll for D, which is referenced in
it's
Bin directory. In that same directory is an old copy of E. D
Click to expand...
copies
BOTH
the new version of D and the old version of E to the local bin directory.
VS goes looking for the Dll for C and finds it. It copies C to the
local
directory. It also looks as C's dependencies and sees that it nees the
new
copy of E. However, it cannot copy the new version of to the /bin
directory, because it just copied the old version of E to the /bin
directory.

The compile fails.

The problem is in the reference to D. Remember, D is not in the solution
(you are not referencing the project, but the DLL itself, and you are
referencing it from D's /bin directory).

Drop the reference to the external dll that references one of the same
dlls
that are already in your library. Recreate the reference, this time
pointing to the /obj directory.

This should fix the problem.

That's why I recommend you simply drop every reference and recreate it.

HTH,
--- Nick

I may be getting closer - somehow even if my Data.DLL project does not
compile a new copy of the DLL ends up in the bin dir of A.DLL, which
makes
me think it's somehow getting hold of an old copy from elsewhere...

Hi Toby,

When you make a reference to a DLL, are you making a reference
Click to expand...
to
the
DLL
in
the /bin directory or the /obj directory?

It matters.

Both work for simple projects. The moment you get into a situation
where
A
references B references C, this becomes very important.

When you make a reference to a dll in the /bin directory, and the
compiler
is searching for all your DLLs to copy to your local directory, it
copies
the dlls from the first referenced directory where they exist. This
may
not
be the one they are referenced from! This is BAD. We want it
Click to expand...
to
copy
the
most recently compiled DLL, but it doesn't. That's why you get this
message.

Go check your references. Better yet. drop them all. (at all levels,
the
problem is usually buried). Recreate them from the OBJ directory
ONLY.

Then, REBUILD everything.

Your problem should go away.

--- Nick

message
I should also mention, that another variation on this theme is that
sometimes I get the "The dependency Data.DLL cannot be copied..."
message
referring to one of the DLLs (say A.DLL), and it can be cured by
deleting
the copy of Data.DLL currently residing in the bin directory
Click to expand...
of
that
Click to expand...
Click to expand...
 
Back
Top