Q: We developed an application using PDFNet SDK for C/C++. Is there
any possibility to avoid our software from breaking if another
application (that uses PDFNet) installs a different version of
PDFNetC.DLL on the same system? Changing the name of the DLL comes to
mind.
-------
A: I assume that you will ship 'PDFNetC.DLL' along with you
application executable (or DLL). In this case your app will use the
version in your application folder. There is no possibility for
collision unless you are copying the DLL in the Windows folder (or
similar) - which is probably not the best idea.
Q: If some other application installs PDFNetC.dll in %SystemRoot%
\SYSTEM32, that application's version of PDFNetC.dll will be loaded
instead of our version of PDFNetC.dll (installed in a different
directory).
Why would some other application want to install PDFNetC.dll in
%SystemRoot%\SYSTEM32?
For avoiding that very problem for *that* application.
-----
A: Your application will first look for PDFNetC.DLL in your
application folder. Only if the DLL is not found, it will look in
system folders. For more information, please see
http://msdn.microsoft.com/en-us/library/ms682586.aspx ('Dynamic-Link
Library Search Order'). Besides the standard search path order for
DLLs there are also other ways to precisely control how and where the
DLL will be loaded from (e.g. manifest files, explicit load path, etc).
Q: In general, we cannot PDFNetC.dll in the directory containing the
EXE file. For instance, we would have to install PDFNetC.dll into C:
\WINDOWS\IE7 to use it in an Internet Explorer plugin as iexplore.exe
lives in that directory. In fact, we install PDFNetC.dll into a
directory shared by all our products and that directory does not
contain any application EXE file. In consequence, Windows will load
PDFNetC.dll from the system directory if it can be found there.
-----
A: For more complicated deployment scenarios, the solutions advocated
by MS is to use "DLL redirection" or "side-by-side components". For
more info please see: