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

On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews" <(E-Mail Removed)> 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 ~~~ (E-Mail Removed)
Microsoft MVP (Visual Basic)

Will this cause any problems when deploying my web app. from a test machine
to the live machine?

"Paul Clement" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews"
<(E-Mail Removed)> 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 ~~~ (E-Mail Removed)
> Microsoft MVP (Visual Basic)

PS I meant to thank you for the advice Paul!

"Toby Mathews" <(E-Mail Removed)> wrote in message
news:cfai8p$jp$(E-Mail Removed)...
> Will this cause any problems when deploying my web app. from a test
machine
> to the live machine?
>
> "Paul Clement" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews"
> <(E-Mail Removed)> 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 ~~~ (E-Mail Removed)
> > 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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews"
<(E-Mail Removed)> 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 ~~~ (E-Mail Removed)
> 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" <(E-Mail Removed)> wrote in message
news:cfal00$1mo$(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews"
> <(E-Mail Removed)> 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 ~~~ (E-Mail Removed)
> > 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" <(E-Mail Removed)> 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" <(E-Mail Removed)> wrote in message
> news:cfal00$1mo$(E-Mail Removed)...
> > 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" <(E-Mail Removed)> wrote in
message
> > news:(E-Mail Removed)...
> > > On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews"
> > <(E-Mail Removed)> 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 ~~~ (E-Mail Removed)
> > > 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" <(E-Mail Removed)> 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" <(E-Mail Removed)> wrote in message
> news:cfal00$1mo$(E-Mail Removed)...
> > 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" <(E-Mail Removed)> wrote in
message
> > news:(E-Mail Removed)...
> > > On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews"
> > <(E-Mail Removed)> 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 ~~~ (E-Mail Removed)
> > > Microsoft MVP (Visual Basic)
> >
> >
>
>

On Tue, 10 Aug 2004 14:23:34 +0100, "Toby Mathews" <(E-Mail Removed)> 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 ~~~ (E-Mail 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

"Toby Mathews" <(E-Mail Removed)> wrote in message
news:cfaqo7$432$(E-Mail Removed)...
> 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" <(E-Mail Removed)> 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" <(E-Mail Removed)> wrote in message
> > news:cfal00$1mo$(E-Mail Removed)...
> > > 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" <(E-Mail Removed)> wrote in
> message
> > > news:(E-Mail Removed)...
> > > > On Tue, 10 Aug 2004 12:28:15 +0100, "Toby Mathews"
> > > <(E-Mail Removed)> 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 ~~~ (E-Mail Removed)
> > > > Microsoft MVP (Visual Basic)
> > >
> > >
> >
> >
>
>