-1

My current project has dependencies on COM components which use side by side manifests. The manifest provided to me contains file elements without any comClass sub-elements like e.g.:

<file name="fred.dll">
</file>

Does this make any sense or can these be deleted safely? Some extra context the manifests were generated automatically in the past. And the given empty entries supposedly have caused issues in the passed, it was explained to me that strange things happen if a process depends on two different COM components that both have a manifest that contains the same empty file element. Furthermore the dll's named in the empty element are straight C dll's that do not contain any COM objects.

I've looked at the available documentation, and the xsd provided by Microsoft tells me that it is syntactically correct to have an empty file element. I have however not found the answer to the question if it makes sense to add file elements to a manifest that don't describe any COM objects.

Bas Bossink
  • 9,388
  • 4
  • 41
  • 53
  • Never tried it, but it should. The client still depends on the registry to create an object but instead of the registered DLL it will load whatever copy is present in the EXE folder. Solves DLL Hell when the author modified the component but did not change guids, a standard crime. Just try it, use a debugger to see where the DLL comes from. – Hans Passant Jan 04 '16 at 13:05
  • @HansPassant: I've updated the question, the dll's are straight C dll's does it make sense then? The dll's would be loaded from the PATH and in this case the dll's get loaded from the EXE folder anyway. – Bas Bossink Jan 04 '16 at 14:16

1 Answers1

1

the dll's are straight C dll's

That's spiraling quickly into the makes-no-sense territory. Technically still useful if the DLL is deployed into a sub-directory with the same name as the dependentAssembly's <assemblyIdentity> name. The OS will not look in sub-directories for a DLL unless told to do so by the manifest. An alternative for side-by-side deployment in the WinSxS cache, using local deployment instead. Note that the subdirectory name is crucial, it must match the "name" attribute of the assemblyIdentity element, best way to recognize the usage.

Jochen Kalmbach gave an example of such manifest use in this blog post. Useful back in the days that Microsoft deployed the CRT into WinSxS (VS2005 and VS2008), a feature that caused wide-spread mayhem. Note the <file> element in the nested Microsoft.VC90.CRT.manifest file.

Whether this usage is a match with what you found is unguessable. Very odd to hide the details in an SO question. Simplest way to find out if it is necessary is to just delete it and see what hits the fan. We can't help you do that.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536