Mihai wrote:
I have 2 projects (VB.NET) : A class library - Proj1
A windows control library - Proj2
I have a reference in proj2 for proj1
In the Build output path of project 1 I put the folder c:\t1
In the Build output path of project 2 I put the folder c:\t2
When I build the proj2 it copies in the c:\t2 the dll for project 1.
Why is this happening ?
Because you added a reference to a Dll that's /not/ in the Global
Assembly Cache, so VB assumed you wanted your own copy of it.
The thinking behind this is that if you [x]copied the whole directory
(including the copied Dll) onto a new machine, it would [probably] run,
because everything the application needs is there.
This /isn't/ as much of a problem as you might think and many people
work this way, with lots (and lots) of physical copies of the same Dll,
running within /different/ applications. It makes each application
resilient, because it has everything it needs and, if you ship an
application with a newer version of the dll, none of the other
applications care; they carry on using their own copy.
It you want to reuse the /same/ Dll in multiple applications, though,
you have to do things differently.
Personally, I put shared assemblies into the Global Assembly Cache (they
have to be Strongly Named, first). Doing this also prevents VB from
taking those [annoying] local copies of Dll's (actually, it's the /only/
way I've found to prevent it!).
Alternatively, you can use (dependentAssem bly and codeBase) entries in
App.Config to tell the application where to look for its Dll's. This
solves the problem at Run-time, but VB will still do its local-copy
thing when you rebuild the project.
HTH,
Phill W.
