Shared dll paths

[Dwight]

I have several projects that use the same dlls. When deploying these
projects, is there a way that I can have all the shared dlls in one
subdirectory and the project specific files in another?

Programs
|
|-App 1
|
|-App 2
|
|-Shared Dlls


Thanks

 

[AMDRIT]

It would probably make better sense to place those dll's in the GAC.

 

[Tom Shelton]

I have several projects that use the same dlls. When deploying these
projects, is there a way that I can have all the shared dlls in one
subdirectory and the project specific files in another?

Programs
|
|-App 1
|
|-App 2
|
|-Shared Dlls


Thanks

Sure, you could do that using the Assembly.LoadFrom method - but, I
think you would be much better off installing those "shared" libraries
to the GAC as has been suggested. That's what it's for after all

 

[Guest]

I have several projects that use the same dlls. When deploying these
projects, is there a way that I can have all the shared dlls in one
subdirectory and the project specific files in another?

You can place them into the GAC, or use reflection to dynamically load
data.

Or you can try configuring multiple private bin directories in your .config
file.

 

[Dwight]

Isn't the GAC only for ASP.net programs?

 

[Dwight]

I see that the GAC is on every computer with the framework. But using
the GAC would require these dlls being loading on users computers,
which is not I want to do.

The applications reside on a network and I've been asked to dump all
programs and dlls into one subdirectory, instead of seperate
directories.

It seems easier to maintain if the applications are in seperate
directories but the client does't want to have multiple copies of the
same dlls and doesn't want to have the dlls loaded on peoples machines.

Thanks

 

[Phill W.]

The applications reside on a network and I've been asked to dump all
programs and dlls into one subdirectory, instead of seperate
directories.

Why? By whom?
Is the program actually going to execute on the client or on the server?

The GAC isn't the only option for loading shared DLL's, but it is one of
the quicker ones. If you /have/ to keep shared DLL's in a separate
directory (and I really /wouldn't/ recommend it), look at the
"dependentAssembly" entry that you can add to your [client program's]
App.Config file. With this, you can hold other [shared] Assemblies
separately from each client program - but Lord help you if you ever try
to move the shared area. ;-)

It seems easier to maintain if the applications are in seperate
directories but the client does't want to have multiple copies of the
same dlls and doesn't want to have the dlls loaded on peoples machines.

So they're prepared to require the 20+Mb Framework on each PC, but not
to manage the <1Mb of your application's DLL's. Lovely ... :-(

Regards,
Phill W.

 

[Dwight]

Why? By whom?
Is the program actually going to execute on the client or on the server?

The applications are stored on a file server with a mapped drive. Users
access the applications from around the world. It is easier to maintain
at the server level than the client level.

The GAC isn't the only option for loading shared DLL's, but it is one of
the quicker ones. If you /have/ to keep shared DLL's in a separate
directory (and I really /wouldn't/ recommend it), look at the
"dependentAssembly" entry that you can add to your [client program's]
App.Config file. With this, you can hold other [shared] Assemblies
separately from each client program - but Lord help you if you ever try
to move the shared area. ;-)

Can the path be a relative path?

So they're prepared to require the 20+Mb Framework on each PC, but not
to manage the <1Mb of your application's DLL's. Lovely ... :-(

Managing the framework is much easier. It's done by a global desktop
team. Managing individual applications is done by project teams. If
there is a way to update the GAC by the application itself, it probably
could be done otherwise it looks everything get dumped into one
subdirectory.

I don't understand the reasoning behind the one directory format yet. I
just have to present pros and cons for both situations.

Thanks

 

[Phill W.]

The applications are stored on a file server with a mapped drive. Users
access the applications from around the world. It is easier to maintain
at the server level than the client level.
Agreed!

... look at the "dependentAssembly" entry that you can add to your
[client program's] App.Config file.

Can the path be a relative path?
Yes.

If there is a way to update the GAC by the application itself, it
probably could be done otherwise it looks everything get dumped
into one subdirectory.

So its there one application that sits "up-front" from which others are
launched? If so, /that's/ the place to put your GAC-installing code,
which most simply, is 'shell'ing out the GacUtil utility, feeding it a
file of assemblies to add.

Regards,
Phill W.

 

[Dwight]

So its there one application that sits "up-front" from which others are
launched? If so, /that's/ the place to put your GAC-installing code,
which most simply, is 'shell'ing out the GacUtil utility, feeding it a
file of assemblies to add.

No, there are just multiple apps. All are independent of each other.

 

[adi]

hi,

the "best" solution (only my opinion)

1) keep the interfaces of your libs compatible => signatures of public
props+methods
(the best is only 1 version of your lib in gac + publisher policy)

2) deploy your libs in the GAC, but only with publisher policies!
this will redirect your "old" clients to the new versions of your libs
=> convince your client that loading from the GAC is much faster!

loading manualy your libs may not be good for the code maintenance of
your libs ... i dont talk at the moment about deployment and moving
your libs in another (network) directory ....

adrian


if you are bored of "manual working" you can use the shareware
"GacPublish" for advanced deployment of assemblies + activeX .... more
after using goooogle
disadvantage => documentation only in german at this time .... english
version will follow?