Avoiding DLL hell with unmanaged applications

Can I leverage assemblies to avoid DLL hell with unmanaged code?

I have an unmanaged application that I have ported from MSVC6 to
Visual Studio 2005. This application is a distributed application
which consists of many components. These components use several third
party DLLs. Furthermore, these components link to several inhouse
static libraries that I would like to convert to DLLs.

I would like to be able to install updated DLLs without breaking
existing applications.

I have managed to create a multifile assembly containing one of my
DLLs and have "installed" it using GACUTIL.

I have no idea how to link my application against my dll in the
assembly. The /reference and /linkresource options that I have seen
mentioned in this regard don't seem applicable.

This is how I created my assembly:

al /link:managerDLLd.dll /platform:x86 /out:managerd.dll /version:1.0.0.0 /keyfile:keypair.snk
CAGUTIL /i managerd.dll

Cheers

.

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: HELP!! Im having "DLL Hell" in .NET
    ... huge known bug if you don't do this (and your dlls are larger than ... It is a client server application with 1 exe as the ... > all the supporting assemblies in directories in the root. ... > true for each reference in these assemblies. ...
    (microsoft.public.dotnet.general)
  • Re: Application security
    ... > - to prevent user from using my dlls directly, ... Assigning strong names to your assemblies is ... The ones you want to protect or the ones from which you want to ... > - I want to manage demo and customers version with license key policy. ...
    (microsoft.public.dotnet.security)
  • Re: Deployment Question
    ... > use those core DLLs. ... > in the system folder and just share them between the two applications. ... deployment method. ... locating assemblies is concerned. ...
    (microsoft.public.vstudio.general)
  • CCW & Managed Memory Leak?
    ... A few of these DLLs have references to .NET assemblies. ... Of course there you do have worker process recycling to help ... I'm confident that if this was running under IIS6 and using the IIS6 ...
    (microsoft.public.dotnet.framework.interop)
Loading