dll path

[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

 

[Phill W.]

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 (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.

 

[Mythran]

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.

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

 

[Mihai]

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

 

[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

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

 

[Phill W.]

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.

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.

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

HTH,
Phill W.

 

[Mythran]

Not necessarily. As I also said:


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

HTH,
Phill W.

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

Mythran

 

[Mihai]

Thanks to both of you, now is clear for me !

Regards,
Mihai