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]

Re: Shared dll paths

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




"Dwight" <dtrumbower@gma il.com> wrote in message
news:1145911450 .595443.32410@u 72g2000cwu.goog legroups.com...[color=blue]
>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
>[/color]

[Tom Shelton]

Re: Shared dll paths


Dwight wrote:[color=blue]
> 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[/color]

Sure, you could do that using the Assembly.LoadFr om 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 :)

--
Tom Shelton [MVP]

[Dwight]

Re: Shared dll paths

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

[Dwight]

Re: Shared dll paths

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

Re: Shared dll paths

Dwight wrote:
[color=blue]
> The applications reside on a network and I've been asked to dump all
> programs and dlls into one subdirectory, instead of seperate
> directories.[/color]

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
"dependentAssem bly" 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. ;-)
[color=blue]
> 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.[/color]

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]

Re: Shared dll paths


Phill W. wrote:[color=blue]
> Why? By whom?
> Is the program actually going to execute on the client or on the server?[/color]

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.
[color=blue]
> 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
> "dependentAssem bly" 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. ;-)[/color]

Can the path be a relative path?

[color=blue]
> 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 ... :-([/color]

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

Re: Shared dll paths

Dwight wrote:[color=blue]
> 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.[/color]

Agreed!
[color=blue][color=green]
>> ... look at the "dependentAssem bly" entry that you can add to your
>> [client program's] App.Config file.[/color]
>
> Can the path be a relative path?[/color]

Yes.
[color=blue]
> 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.[/color]

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]

Re: Shared dll paths


Phill W. wrote:
[color=blue]
> 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.[/color]

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

[adi]

Re: Shared dll paths

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?