Unmanaged Multifile Assembly in C++

I have several unmanaged C++ dlls that were being shared by several
projects which were successfully converted to assemblies. However one
of those dlls is dependent on another dll which we currently handle by
putting it in a folder under Common Files and adding the location the
the "Path" environment variable. We'd really like to avoid doing this
however so I've been looking into packaging the two dlls together into
a single assembly.

Unfortunately all the documentation in msdn seems aimed at
constructing VB and C# assemblies using al.exe and do not seem
applicable to the situation I'm in using C++. After looking at the
example of the VC80 CRT dlls in WinSxS I've come up with a process
that seems to create a multifile assembly which can be installed
properly. When I examine the file structure after installation
everything seems correct, but when I try to use the assembly it fails.
Dependency Walker seems to think that the first dll cannot access the
second dll which is residing in the same folder. If I add the second
dll to the path I am running the program from it works correctly.

What do I need to change either about the first file or about the
assembly construction process so that it can find the second file?

The process I am currently using is to compile all the files as normal
(not embedding a manifest in file01 but embedding one in file02.) I
then modify the external manifest for file01 to add the line:

<file name="file02.dll"
hash="0000000000000000000000000000000000000000" hashalg="SHA1"></file>
(This goes just below the identical file reference for file01.dll)

Then perform the same steps as when creating a single file assembly:

mt -manifest "file01.manifest" -outputresource:file01.dll;2

mt -manifest file01.manifest -hashupdate -makecdfs

makecat file01.manifest.cdf

signtool sign /f Keys\OurKey.pfx /t http://timestamp.verisign.com/scripts/timestamp.dll
file01.cat

This results in file01.manifest (with file elements for both file01
and file02, including hashes, DigestValues, etc) file01.cat,
file01.dll, and file02.dll.

Thanks for any help anyone can provide!

.

Relevant Pages

  • 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)
  • 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)
  • Re: Appl. Security Problems
    ... Back up your compiled assemblies (the EXE and both DLLs) and your CAS ... the key is only used to sign the assembly at compile time. ...
    (microsoft.public.dotnet.security)
  • Re: What can we call such a framework
    ... as all the assemblies will be dependent on the version on which they were built. ... What would happen if the core is built in Delphi 6, a the modules are build as DLLs in VC++ 6 or LCC 'C'? ...
    (borland.public.delphi.non-technical)
Quantcast