dll path

  • Thread starter Thread starter Mihai
  • Start date Start date
M

Mihai

For example:
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

The startup project is Proj2
When I build the proj2 it copies in the c:\t2 the dll for project 1. Why is
happening this ? How can I modified this?Because I put the reference in
proj2 the dll from the folder c:\t1 .I want allways to take from c:\t1 , not
to copy the dll for proj1 in c:\t2.

Thank,
Mihai
 
Mihai said:
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
Click to expand...
When I build the proj2 it copies in the c:\t2 the dll for project 1.
Click to expand...
Why is this happening ?
Click to expand...

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 (dependentAssembly 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.
 
Phill W. said:
Alternatively, you can use (dependentAssembly 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.
Click to expand...

Phil,

You can also go to the properties for the reference and change the "Copy
Local" property to False. This prevents the copy.

HTH,
Mythran
 
After I changed the reference property Copy local = False it gives me an
error : Could not load file or assembly Proj1.dll or one of its
dependencies.Invalid pointer.
What is this guys ! It kills me all this error messages.

Thank you,
Mihai
 
Mihai said:
After I changed the reference property Copy local = False it gives me an
error : Could not load file or assembly Proj1.dll or one of its
dependencies.Invalid pointer.
What is this guys ! It kills me all this error messages.

Thank you,
Mihai
Click to expand...

Once copy-local is set to False, you have to install the assembly into the
GAC so the application can load it, as Phill stated in his previous reply.

HTH,
Mythran
 
Mythran said:
Once copy-local is set to False, you have to install the assembly into
the GAC so the application can load it, as Phill stated in his previous
reply.
Click to expand...

Not necessarily. As I also said:
Alternatively, you can use (dependentAssembly and codeBase) entries in
App.Config to tell the application where to look for its Dll's.
Click to expand...

And /relative/ paths do work (at least in VB'2003)!

HTH,
Phill W.
 
Phill W. said:
Not necessarily. As I also said:


And /relative/ paths do work (at least in VB'2003)!

HTH,
Phill W.
Click to expand...

Yes, I know this but didn't mention it in my previous reply. Thanks for
correcting it.

Mythran
 
Back
Top