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
24  1760 
On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote:
¤ 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/de...ndencyFile.asp
Yes. Strong name your assemblies and register them with the GAC (Global Assembly Cache).
Paul ~~~ pc******@ameritech.net
Microsoft MVP (Visual Basic)
On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote:
¤ 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/de...ndencyFile.asp
Yes. Strong name your assemblies and register them with the GAC (Global Assembly Cache).
Paul ~~~ pc******@ameritech.net
Microsoft MVP (Visual Basic)
Will this cause any problems when deploying my web app. from a test machine
to the live machine?
"Paul Clement" <Us***********************@swspectrum.com> wrote in message
news:q9********************************@4ax.com... On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews"
<to***************@yahoo.spamfree.co.uk> wrote:
¤ 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/de...ndencyFile.asp
Yes. Strong name your assemblies and register them with the GAC (Global
Assembly Cache).
Paul ~~~ pc******@ameritech.net
Microsoft MVP (Visual Basic)
Will this cause any problems when deploying my web app. from a test machine
to the live machine?
"Paul Clement" <Us***********************@swspectrum.com> wrote in message
news:q9********************************@4ax.com... On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews"
<to***************@yahoo.spamfree.co.uk> wrote:
¤ 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/de...ndencyFile.asp
Yes. Strong name your assemblies and register them with the GAC (Global
Assembly Cache).
Paul ~~~ pc******@ameritech.net
Microsoft MVP (Visual Basic)
PS I meant to thank you for the advice Paul!
"Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf*********@thorium.cix.co.uk... Will this cause any problems when deploying my web app. from a test
machine to the live machine?
"Paul Clement" <Us***********************@swspectrum.com> wrote in message
news:q9********************************@4ax.com... On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote:
¤ 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/de...ectoryBecauseI
tWouldConflictWithDependencyFile.asp
Yes. Strong name your assemblies and register them with the GAC (Global
Assembly Cache).
Paul ~~~ pc******@ameritech.net
Microsoft MVP (Visual Basic)
PS I meant to thank you for the advice Paul!
"Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf*********@thorium.cix.co.uk... Will this cause any problems when deploying my web app. from a test
machine to the live machine?
"Paul Clement" <Us***********************@swspectrum.com> wrote in message
news:q9********************************@4ax.com... On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote:
¤ 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/de...ectoryBecauseI
tWouldConflictWithDependencyFile.asp
Yes. Strong name your assemblies and register them with the GAC (Global
Assembly Cache).
Paul ~~~ pc******@ameritech.net
Microsoft MVP (Visual Basic)
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?
"Paul Clement" <Us***********************@swspectrum.com> wrote in message
news:q9********************************@4ax.com... On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews"
<to***************@yahoo.spamfree.co.uk> wrote:
¤ 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/de...ectoryBecauseI
tWouldConflictWithDependencyFile.asp
Yes. Strong name your assemblies and register them with the GAC (Global
Assembly Cache).
Paul ~~~ pc******@ameritech.net
Microsoft MVP (Visual Basic)
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?
"Paul Clement" <Us***********************@swspectrum.com> wrote in message
news:q9********************************@4ax.com... On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews"
<to***************@yahoo.spamfree.co.uk> wrote:
¤ 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/de...ectoryBecauseI
tWouldConflictWithDependencyFile.asp
Yes. Strong name your assemblies and register them with the GAC (Global
Assembly Cache).
Paul ~~~ pc******@ameritech.net
Microsoft MVP (Visual Basic)
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" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf**********@thorium.cix.co.uk... 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?
"Paul Clement" <Us***********************@swspectrum.com> wrote in message
news:q9********************************@4ax.com... On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote:
¤ 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/de...ectoryBecauseI tWouldConflictWithDependencyFile.asp
Yes. Strong name your assemblies and register them with the GAC (Global
Assembly Cache).
Paul ~~~ pc******@ameritech.net
Microsoft MVP (Visual Basic)
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" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf**********@thorium.cix.co.uk... 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?
"Paul Clement" <Us***********************@swspectrum.com> wrote in message
news:q9********************************@4ax.com... On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote:
¤ 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/de...ectoryBecauseI tWouldConflictWithDependencyFile.asp
Yes. Strong name your assemblies and register them with the GAC (Global
Assembly Cache).
Paul ~~~ pc******@ameritech.net
Microsoft MVP (Visual Basic)
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" <ni*******@hotmail.nospam.com> wrote in message
news:_k5Sc.123928$eM2.40348@attbi_s51... 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" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf**********@thorium.cix.co.uk... 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?
"Paul Clement" <Us***********************@swspectrum.com> wrote in
message news:q9********************************@4ax.com... On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote:
¤ 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/de...ectoryBecauseI tWouldConflictWithDependencyFile.asp
Yes. Strong name your assemblies and register them with the GAC
(Global Assembly Cache).
Paul ~~~ pc******@ameritech.net
Microsoft MVP (Visual Basic)
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" <ni*******@hotmail.nospam.com> wrote in message
news:_k5Sc.123928$eM2.40348@attbi_s51... 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" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf**********@thorium.cix.co.uk... 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?
"Paul Clement" <Us***********************@swspectrum.com> wrote in
message news:q9********************************@4ax.com... On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote:
¤ 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/de...ectoryBecauseI tWouldConflictWithDependencyFile.asp
Yes. Strong name your assemblies and register them with the GAC
(Global Assembly Cache).
Paul ~~~ pc******@ameritech.net
Microsoft MVP (Visual Basic)
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" <ni*******@hotmail.nospam.com> wrote in message
news:_k5Sc.123928$eM2.40348@attbi_s51... 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" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf**********@thorium.cix.co.uk... 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?
"Paul Clement" <Us***********************@swspectrum.com> wrote in
message news:q9********************************@4ax.com... On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote:
¤ 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/de...ectoryBecauseI tWouldConflictWithDependencyFile.asp
Yes. Strong name your assemblies and register them with the GAC
(Global Assembly Cache).
Paul ~~~ pc******@ameritech.net
Microsoft MVP (Visual Basic)
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" <ni*******@hotmail.nospam.com> wrote in message
news:_k5Sc.123928$eM2.40348@attbi_s51... 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" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf**********@thorium.cix.co.uk... 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?
"Paul Clement" <Us***********************@swspectrum.com> wrote in
message news:q9********************************@4ax.com... On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote:
¤ 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/de...ectoryBecauseI tWouldConflictWithDependencyFile.asp
Yes. Strong name your assemblies and register them with the GAC
(Global Assembly Cache).
Paul ~~~ pc******@ameritech.net
Microsoft MVP (Visual Basic)
On Tue, 10 Aug 2004 14:23:34 +0100, "Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote:
¤ 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 ~~~ pc******@ameritech.net
Microsoft MVP (Visual Basic)
On Tue, 10 Aug 2004 14:23:34 +0100, "Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote:
¤ 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 ~~~ pc******@ameritech.net
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
"Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf**********@thorium.cix.co.uk... 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" <ni*******@hotmail.nospam.com> wrote in message
news:_k5Sc.123928$eM2.40348@attbi_s51... 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" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf**********@thorium.cix.co.uk... 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?
"Paul Clement" <Us***********************@swspectrum.com> wrote in message news:q9********************************@4ax.com...
> On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews"
<to***************@yahoo.spamfree.co.uk> wrote:
>
> ¤ 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/de...ectoryBecauseI tWouldConflictWithDependencyFile.asp
>
> Yes. Strong name your assemblies and register them with the GAC (Global Assembly Cache).
>
>
> Paul ~~~ pc******@ameritech.net
> 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
"Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf**********@thorium.cix.co.uk... 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" <ni*******@hotmail.nospam.com> wrote in message
news:_k5Sc.123928$eM2.40348@attbi_s51... 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" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf**********@thorium.cix.co.uk... 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?
"Paul Clement" <Us***********************@swspectrum.com> wrote in message news:q9********************************@4ax.com...
> On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews"
<to***************@yahoo.spamfree.co.uk> wrote:
>
> ¤ 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/de...ectoryBecauseI tWouldConflictWithDependencyFile.asp
>
> Yes. Strong name your assemblies and register them with the GAC (Global Assembly Cache).
>
>
> Paul ~~~ pc******@ameritech.net
> Microsoft MVP (Visual Basic)
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
"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:1vgSc.265602$JR4.97773@attbi_s54... 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
"Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf**********@thorium.cix.co.uk... 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" <ni*******@hotmail.nospam.com> wrote in message
news:_k5Sc.123928$eM2.40348@attbi_s51... 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" <to***************@yahoo.spamfree.co.uk> wrote in
message news:cf**********@thorium.cix.co.uk...
> 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?
>
> "Paul Clement" <Us***********************@swspectrum.com> wrote in
message > news:q9********************************@4ax.com...
> > On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews"
> <to***************@yahoo.spamfree.co.uk> wrote:
> >
> > ¤ 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/de...ectoryBecauseI > tWouldConflictWithDependencyFile.asp
> >
> > Yes. Strong name your assemblies and register them with the GAC
(Global > Assembly Cache).
> >
> >
> > Paul ~~~ pc******@ameritech.net
> > Microsoft MVP (Visual Basic)
>
>
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
"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:1vgSc.265602$JR4.97773@attbi_s54... 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
"Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf**********@thorium.cix.co.uk... 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" <ni*******@hotmail.nospam.com> wrote in message
news:_k5Sc.123928$eM2.40348@attbi_s51... 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" <to***************@yahoo.spamfree.co.uk> wrote in
message news:cf**********@thorium.cix.co.uk...
> 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?
>
> "Paul Clement" <Us***********************@swspectrum.com> wrote in
message > news:q9********************************@4ax.com...
> > On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews"
> <to***************@yahoo.spamfree.co.uk> wrote:
> >
> > ¤ 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/de...ectoryBecauseI > tWouldConflictWithDependencyFile.asp
> >
> > Yes. Strong name your assemblies and register them with the GAC
(Global > Assembly Cache).
> >
> >
> > Paul ~~~ pc******@ameritech.net
> > Microsoft MVP (Visual Basic)
>
>
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
"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:1vgSc.265602$JR4.97773@attbi_s54... 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
"Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf**********@thorium.cix.co.uk... 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" <ni*******@hotmail.nospam.com> wrote in message
news:_k5Sc.123928$eM2.40348@attbi_s51... 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" <to***************@yahoo.spamfree.co.uk> wrote in
message news:cf**********@thorium.cix.co.uk...
> 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?
>
> "Paul Clement" <Us***********************@swspectrum.com> wrote in
message > news:q9********************************@4ax.com...
> > On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews"
> <to***************@yahoo.spamfree.co.uk> wrote:
> >
> > ¤ 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/de...ectoryBecauseI > tWouldConflictWithDependencyFile.asp
> >
> > Yes. Strong name your assemblies and register them with the GAC
(Global > Assembly Cache).
> >
> >
> > Paul ~~~ pc******@ameritech.net
> > Microsoft MVP (Visual Basic)
>
>
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
"Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf**********@thorium.cix.co.uk... 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
"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:1vgSc.265602$JR4.97773@attbi_s54... 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
"Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf**********@thorium.cix.co.uk... 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" <ni*******@hotmail.nospam.com> wrote in message
news:_k5Sc.123928$eM2.40348@attbi_s51...
> 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" <to***************@yahoo.spamfree.co.uk> wrote in message > news:cf**********@thorium.cix.co.uk...
> > 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?
> >
> > "Paul Clement" <Us***********************@swspectrum.com> wrote in
message
> > news:q9********************************@4ax.com...
> > > On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews"
> > <to***************@yahoo.spamfree.co.uk> wrote:
> > >
> > > ¤ 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/de...ectoryBecauseI > > tWouldConflictWithDependencyFile.asp
> > >
> > > Yes. Strong name your assemblies and register them with the GAC
(Global
> > Assembly Cache).
> > >
> > >
> > > Paul ~~~ pc******@ameritech.net
> > > Microsoft MVP (Visual Basic)
> >
> >
>
>
Yup, B.DLL refers to Data\obj\debug\Data.dll.
:-(
"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:kNlTc.6065$mD.1507@attbi_s02... 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
"Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf**********@thorium.cix.co.uk... 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
"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:1vgSc.265602$JR4.97773@attbi_s54... 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
"Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote in
message news:cf**********@thorium.cix.co.uk...
> 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" <ni*******@hotmail.nospam.com> wrote in message
> news:_k5Sc.123928$eM2.40348@attbi_s51...
> > 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" <to***************@yahoo.spamfree.co.uk> wrote in
message > > news:cf**********@thorium.cix.co.uk...
> > > 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?
> > >
> > > "Paul Clement" <Us***********************@swspectrum.com> wrote
in > message
> > > news:q9********************************@4ax.com...
> > > > On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews"
> > > <to***************@yahoo.spamfree.co.uk> wrote:
> > > >
> > > > ¤ 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/de...ectoryBecauseI > > > tWouldConflictWithDependencyFile.asp
> > > >
> > > > Yes. Strong name your assemblies and register them with the
GAC > (Global
> > > Assembly Cache).
> > > >
> > > >
> > > > Paul ~~~ pc******@ameritech.net
> > > > Microsoft MVP (Visual Basic)
> > >
> > >
> >
> >
>
>
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" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf**********@thorium.cix.co.uk... Yup, B.DLL refers to Data\obj\debug\Data.dll.
:-(
"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:kNlTc.6065$mD.1507@attbi_s02... 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
"Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote in message
news:cf**********@thorium.cix.co.uk... 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
"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:1vgSc.265602$JR4.97773@attbi_s54...
> 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
>
> "Toby Mathews" <to***************@yahoo.spamfree.co.uk> wrote in message > news:cf**********@thorium.cix.co.uk...
> > 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" <ni*******@hotmail.nospam.com> wrote in message
> > news:_k5Sc.123928$eM2.40348@attbi_s51...
> > > 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" <to***************@yahoo.spamfree.co.uk> wrote in
message
> > > news:cf**********@thorium.cix.co.uk...
> > > > 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? > > > >
> > > > "Paul Clement" <Us***********************@swspectrum.com>
wrote in > > message
> > > > news:q9********************************@4ax.com...
> > > > > On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews"
> > > > <to***************@yahoo.spamfree.co.uk> wrote:
> > > > >
> > > > > ¤ 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/de...ectoryBecauseI > > > > tWouldConflictWithDependencyFile.asp
> > > > >
> > > > > Yes. Strong name your assemblies and register them with the GAC > > (Global
> > > > Assembly Cache).
> > > > >
> > > > >
> > > > > Paul ~~~ pc******@ameritech.net
> > > > > Microsoft MVP (Visual Basic)
> > > >
> > > >
> > >
> > >
> >
> >
>
>
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: kayodeok |
last post by:
We're Mad As Hell And We're Not Going To Take It Anymore
http://hownow.brownpau.com/index.html
The web is a mess. We're tired of this deluge of <font> tags, nested
tables, spacer GIFs, and...
|
by: .DLL hell II - The Evil Empire Strikes Back |
last post by:
I can't figure out how this side-by-side assembly stuff it
supposed to work.
I have a stack of four assemblies
A has no references
B references A & C
C References A & B
D References A, B and C...
|
by: Jim Hubbard |
last post by:
I am reposting a portion of a thread that I am involved in under a new topic
because it seems that there are still people that believe the whole "DLL
Hell" myth.
I hope I can shed some light on...
|
by: Nad |
last post by:
Hello,
dll hell has been eliminated in .NET using assembly versioning.
I am new in .NET and would like to know if there is any dll-hell-equivalent
in .NET Windows or Web development...
|
by: Nx |
last post by:
Hi
I am unpacking a list into variables, for some reason they need to be
unpacked into variable names like a0,a1,a2....upto aN whatever is
in the list.
How to create the variables dynamically...
|
by: GreatB |
last post by:
Bill Gates died in a car accident.
He found himself in Purgatory being sized up by God .
.. "Well, Bill, I'm really confused on this call. I'm
not sure whether to send you to Heaven or Hell....
|
by: Dave Sauny |
last post by:
Ok, its a friday, I'm at work and I cant get this to work:
I have 3 listboxes on one tab control page. when i select an item in
listbox1 i want whatever is selected on the other 2 listboxes...
|
by: fyleow |
last post by:
I just spent hours trying to figure out why even after I set my SQL
table attributes to UTF-8 only garbage kept adding into the database.
Apparently you need to execute "SET NAMES 'utf8'" before...
|
by: Scott M. |
last post by:
I need a little help please...
I'm simply trying to set up a very basic event for a class and then create
an event handler for that class in a Console application.
I think I'm very close, but...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
