Re: Deployment Question

From: Phill. W (P.A.Ward_at_o-p-e-n-.-a-c-.-u-k)
Date: 02/01/05 

Date: Tue, 1 Feb 2005 13:21:06 -0000

"Dave M." <nospam@ihatesmap.com> wrote in message
news:uzvjaS%23BFHA.3596@TK2MSFTNGP12.phx.gbl...
> I have one solution that has a number of .DLLs, and 2 applications that
> use those core DLLs. When I try to build a deployment package for
> my applications, I figured it was a good idea to put the .DLLs
> in the system folder and just share them between the two applications.

First problem. The .Net Framework /does not/ search the DOS
path to locate DLL's; it has its own wierd[er] and [more] wonderful
"Rules" for working things out.

> If I keep the .dll in the Application Folder, the application works.

That's one way of making it work; the much lauded "XCopy"
deployment method. The application can find anything in its own
directory. Many people see this as a perfectly good deployment
strategy, with every application having its own copy of any shared
assemblies.

Suffice to say, I don't.

> I tried different ways of registering (None, COM, Relative)

The one you've missed is putting it into the Global Assembly Cache,
or GAC. This seems to be .Net's version of the Registry as far as
locating assemblies is concerned. Adding your assembly into the
GAC makes is accessible anywhere on the machine (i.e. from any
application - Security Permissions .. er .. permitting).

> It seems silly to have the .dlls in 2 places, especially for updating
> purposes.

I agree, although deploying the file as part of each application does
have the singular advantage that you can [supposedly] update the
Dll while the application is still running; it will simply "reload" the
new Dll as and when it needs to. Assemblies loaded into the GAC
are /not/ picked up until the application is restarted.

HTH,
    Phill W.

Relevant Pages

  • Re: Deployment Question
    ... > applications that use those core DLLs. ... Put the assemblies in the bin folders of their respective apps. ... I would go ahead with the simple XCopy deployment. ...
    (microsoft.public.vstudio.general)
  • Re: Deployment Question
    ... >> applications that use those core DLLs. ... >> .DLLs in the system folder and just share them between the two ... I would go ahead with the simple XCopy deployment. ...
    (microsoft.public.vstudio.general)
  • Avoiding DLL hell with unmanaged applications
    ... Can I leverage assemblies to avoid DLL hell with unmanaged code? ... static libraries that I would like to convert to DLLs. ... existing applications. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: D2007 - mind-numbing obstacles after upgrading
    ... We avoid stuff like packages and DLLs since it makes deployment of ... applications so much more complex - our apps roll out to thousands of ... deployment takes on a new face entirely. ...
    (borland.public.delphi.non-technical)
  • Re: Same assembly in different deployments
    ... I have created a class library, when builded it produces a dll called test.dll. ... When I create a deployment project, this dll is added to the output and is shipped with the application. ... How can I change the setup/code/properties so the application will look in a different directory for this particular assembly at runtime, while it look for other assemblies in the application path? ... that it is not an option to install ALL applications in the same directory. ...
    (microsoft.public.dotnet.languages.csharp)