The blogged wandering of Robert W. Anderson
In my previous post, Ah, it was DLL hell, I said I still have a problem. The problem is with Server 2003 registration-free COM and a custom-generated manifest. XP and Server 2003 have different requirements for the location of dependent assemblies, so it isn’t suprising that they might behave differently. Anyway, now that I’ve gotten past my initial issue, the problem is clear. Well, as clear as can be expected with registration-free COM.
The event log said (reformatted and abbreviated for readability):
Syntax error in manifest or policy file
"C:\\ . . . \\DigipedeAutoManifest.manifest" on line 4.
The value of attribute "name"
element "urn:schemas-microsoft-com:asm.v1^file" is invalid.
The name attribute was a full path to the DLL containing the COM server to be activated. I changed it to a relative path and now it works just fine. The DLL is in the same directory as the manifest (rooted below the executable).
I know for a fact that the full path used to work on Server 2003. I can only guess this was changed by some Windows Update in the past six months.
Now I’ve fixed our code to be compatible with the change.
BTW: the required syntax seems to be
<file name="./comserver.dll">. It doesn’t work without the
./. Thanks to Steve White — his articles on registration-free COM are very helpful.
I’ve been planning a post about the evils of DLLs. My basic thesis is that a lot of people are using them gratuitously and thus getting themselves into unneeded trouble down the road. I think DLLs should generally only be used for interfacing between different vendors or adding “plug-in” type functionality. What do you think?
I agree that DLLs can be used excessively. From the perspective of maintenance and automated builds, load performance, etc., every extra DLL can have a real cost. Of course, shared DLLs have performance benefits too (e.g., sharing memory across processes).
I don’t agree that “different vendors or adding plugin” is a sufficient metric. For example, the Digipede Network has several components (Agent, IIS applications, Services, tools, etc.) that require shared definitions of data. While it is possible, there is no reasonable way to share this without DLLs (in .NET).
Energy Interactive had the same situation.
So, flame away on DLLs if you like, but they aren’t the evil. Versioning is the evil part.
Actually EI is a good example of the gratuitous use of DLLs and the ills that it can cause. I don’t remember any shared data definitions that necessitated the use of DLLs. We couldn’t distribute Energy Profiler, E-VEE, or Energy BOSS on the same machine without them potentially breaking each other. And they did. I once made a new version of E-VEE that fixed a bunch of customer problems and we couldn’t deploy it because it could theoretically have broken BOSS and we hadn’t done a full system test of that version of BOSS with the new E-VEE version. We considered moving all the DLLs into special directories for E-VEE but that wouldn’t solve the problem because of the single-registration issue with the COM components.
OK, so may be it was gratuitous at EI. There was a time when it was worse with TK, WL, AL, and GL. Merging most of those improved the situation.
There was shared data definition in that the DCOM contracts were defined in EIJOBMGR and shared between it and the business rules. Of course that part could have been shared in another way.
The real culprit here, though, was COM.
Thank you for this post, as we are having similar issues.
Do you run on Windows XP. We found that we needed double backslashes in the path.
My main worry is the next microsoft hotfix / service patch which changes the behaviour again.
Tim, thanks for the comment.
We support both Windows XP as well as Server 2003 (Server 2000 too, but of course, side-by-side is not supported on that OS).
You say that you needed double backslashes, but does a single forward slash work instead?
I also am concerned that a future patch will change the behavior. Unfortunately, it is almost impossible for us (as ISVs) to map the flood of patches against behavioral changes like this.
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>