The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Embeded a manifest file into a COM DLL

Recently, when I attempted to embed a manifest into a isolated dll(the manifest contains the dll's dependencey,  a stack of other COMs ), then I registered this COM and loaded it by another test application. obviously, it succeeded in calling the method of the registered COM itself, but when I call other COM's method through the method of the registered COM, Failed in the end. Can anybody tell me why and how to fix it, by the way, I don't want to embed the manifest file into the test application.
Arthur Jiang Send private email
Wednesday, November 28, 2007
 
 
Assuming you have created a proper manifest to begin with, you can recalculate the <file> hash values and embed it into the "client" DLL/OCX by using MT.EXE.

Alternatively you can recalc the hashes yourself via CAPICOM or the Crypto API (or skip the optional hashes altogether, or calc them manually) and use BeginUpdateResource() and friends in kernel32 to insert the manifest as a resource.

Or you can go the RC.EXE route and LINK the compiled resource into the client DLL.

Or you can use the resource management functionality of your development tools (which may mean RC.EXE again).


It depends on what you're doing.


The real question I'd ask is why you isolate the dependencies and then register this client DLL at all?  Why not isolate that too and free the consumer of registry contamination and DLL Hell?  But that's your call.
Codger
Wednesday, November 28, 2007
 
 
Many thanks to Codger, But I want to investigate is to see that, for example, there are two different applications, A.exe and B.exe. both of them are depend on C.dll. moreover, C.dll depend on D.dll and E.dll..., therefore, If I want to call D.dll or E.dll's method through C.dll, I need to merge the D.dll or E.dll's isolation information into the application's manifest file. so I wander whether could I embeded D.dll or E.dll's manifest into C.dll, then the application is free to know what is C.dll depend on when call C.dll. However, I failed in the end, I don't clearly know why and how to fix this problem, can anybody help me?
Arthur Jiang Send private email
Friday, November 30, 2007
 
 
It sounds as if you are trying to get by with a "flat" manifest hierarchy with just application manifests.  I believe you can get away with this as long as you have one application manifest per EXE.

These manifests for your A.exe and B.exe will be rather similar.  Both of them will include <file/> elements for each of C.dll, D.dll, and E.dll without regard to any hierarchy of calls.

Alternatively, you could have assembly manifests for each of C, D, and E, and an application manifest for each of A and B.  The application manifests for A and B would each contain a <dependency/> for C pointing to C's assembly manifest, and the assembly manifest for C would contain a <depedndency/> for each of D and E.

But that's just a guess based on two interpretations of what you're asking and my own limited experience.  I find the documentation of this subject remarkably poor.
Codger
Friday, November 30, 2007
 
 
Thanks to Codger, you are really very kind hearted.
Maybe the second way is feasible. but I'm not quit clear about how to easily get the dll's assembly manifest,
I've been searching for this and something else such as share assembly all the time, but only a little resource can i find and doesn't do much material work. if you know, could you give me a example. Thanks in advance.
Arthur Jiang Send private email
Sunday, December 02, 2007
 
 
I'm struggling a little to understand this yet.

It sounds like C has an isolation manifest and is a client itself to both D and E.

Then for whatever reason you registered C and linked to C from programs A and B using registration info instead of with application manifests for A and B.  This appears to fail.

All I can imagine is that when A and B start, their activation contexts are derived from the registration source and then the embedded manifest in C is ineffective.  The only "cure" I can think of involves shared assemblies of course, but I'm not quite sure that simply registering C accomplishes this.

I'd guess that some special form of registration is required in order to do SxS sharing.  I can imagine "shared isolation" where both A and B have application manifests pointing to a shared C assembly that contains C, D, and E.

Without using application manifests in A and B though I'm not sure you can make this work.

Maybe somebody else can shed more light on this.
Codger
Monday, December 03, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz