Manifest for my own (native) DLL

1
votes

NOTE: This question is not about MFC/CRT DLL linking with/without .manifest file, avoiding manifest-lookup (i.e. force load from current path), VC redist installation and similar issues.

I have set of DLLs, which is used by different applications. These applications and the DLL have some product version (like 7.0, 8.0 etc). To summarize, let me use one DLL, and two applications.

  • App.exe depends on Core.DLL
  • GoodApp.exe also depends on Core.DLL

App.EXE of version 7.0 would need Core.DLL of version 7.0. Similary, GoodApp of version X, would need DLL of version X.

Since DLL is to be shared by different applications, I have put the DLL into some common path. This avoids DLL to be pasted on all paths. Some \SharedDLL path is setup for this. And (assume), I have set up PATH variable for this. So, when any of application would load, OS will simply load the Core.DLL from this common path.

All fine. But what if App.exe is 64-bit/Debug, or other configuration? The common-DLL path cannot have all DLLs (32/64, Debug/Release). On the similar lines, App.exe of version Y, cannot use Core.DLL of version X (It is not that X>Y, or Y>X, but just that X!=Y, and App of X version cannot use DLL of version Y).

In short, App-32bit-Release-VersionX, would need exactly DLL-32bit-Release-VersionX, and nothing else! Since DLL name is same, I cannot put them into one common path. And since, there are dozens of applications (and DLLs too!) that depends on Core.DLL, I just don't want to waste space and time for copying the DLL into EXE's path.

Yes, I use post-build-setup to copy the DLL into all paths, appropriately. This solves time, but waste space. And if new application comes in, PBS must be modified to copy to that new path also.

Question is: How to utilizie the .manifest feature, used by Windows/MFC/CRT DLLs? They do utilize WinSxS folder for such thing.

1
visual-c++dllversioningmanifestside-by-side
Step back for a minute and review what you asked. You are asking for a way to not share DLLs. That's already really simple, give each EXE its own copy of the DLL by copying it in the same directory as the EXE. The side-by-side cache solves a problem that's specific to Microsoft. – Hans Passant
Yes, so DLLs are very much specific to Microsoft! I have read about shared/private assemblies, and about how to structure the XML for "custom" (non-MS) DLLs. Didn't get enough time to try-n-test it fully! And I want to avoid that "simple" thing of copying the DLLs! – Ajay
No, specific to Microsoft's DLLs. They made the mistake to put DLLs in directories that are on the PATH. Don't ever make the same mistake. – Hans Passant

1 Answers