Re: Singleton MFC Extension DLL

"Ajay Kalra" <ajaykalra@yahoo.com> wrote in message
news:b88cebfe-6c4c-4255-b562-1c55c1ac58cc@z7g2000vbl.googlegroups.com...


I see, yes we are talking about the same thing. When I found out that
checking the box in Project Dependencies made specifying the .lib in the
linker line unnecessary, I stopped adding it, but I certainly can see for
non-trivial cases it would be valuable to still add it. I actually had an
issue where my .exe was dependent on the .dll but I did not want to
staticallly link to it because I did not want it loaded on startup because
the DLL required a specific version of Windows or later, and it would fail
to load if the .exe was run on an earlier version of Windows. (The .exe
checked the Windows version and only loaded the DLL via LoadLibrary if the
version was recent enough to support the DLL. [*]) In this case, there is a
handy setting "Ignore Import library" in the Linker settings that cause the
..lib *not* to be linked in automatically to the .exe (or other projects
dependent on the .dll). I believe the similar setting for static libs is
"Link Library Settings" in the Librarian settings. (These are for VS2005.)

---
[*] An easier way to avoid the DLL issue would have been to use delay-load
DLL's which cause the DLL not to be loaded until the first call to it. If
the .exe determines the Windows does not support the DLL, the .exe just
jumps over the code that would call its functions and the DLL would never be
loaded. But delay-loading a DLL requires delayload.lib (or something like
that) to be linked into the .exe which added some bloat to the .exe size
which in my case was not desireable. So I did it the hard way.

Thanks,
David