DLL DEBUG MODE IN CPP

[=?Utf-8?B?V2lsbGlhbSBNY0lscm95?=]

Here's the problem. I've been developing a C++ application since 2003 using
the default settings. Comes time to find all the memory leaks. I downloaded
a nifty package that won't work unless I use the debug library DLLs. I get
nothing but complaints from Visual Studio 2008. On <name-of-appProperty
Page I change Use of MFC to Shared DLL. This presents a problem. I am told
that the Linker is conflicted as follows: LINK : warning LNK4098: defaultlib
'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library. Oh my.
I told the IDE to do a debug compile and link. Apparently not all necessary
changes happened automagically. However, the build succeeded. Upon launch,
the loader complains as follows: This application has failed to start
because mfc90d.dll was not found. Re-installing the application may fix this
problem. Or --- it may not. Further fooling around produces complaints
about a manifest that either does not exist or contains nonsense. Question:
Is there a quick and easy way to shift from Standard Windows Libraries to DLL
Debug Mode that doesn't involve poke and hope?
--
William McIlroy

[Ismo Salonen]

--snip--

You cannot mix debug and release mode dlls, all modules
should be compiled with same switches. Also some preprocessor defines
must be same as they change the layout of internal classes.

Also you cannot deploy visual studio debug mode libraries,
you must debug on your own computer.

So you have created huge application with release mode only ? never
tested debug mode ? in debug mode there are quite a lot of checks which
help you to detect problems like memory leaks in early stages.

You can also use some memory leak detectors in release mode, e.g Purify
and GlowCode are such products, glowcode might still have demo version
to test.

ismo

[=?Utf-8?B?V2lsbGlhbSBNY0lscm95?=]

I'm the original poster. It turns out the large C++ program that I developed
has suffered numerous automated migrations through Visual Studios 2003, 2005,
and 2008. The end result is a project that uses (the deprecated?) BSCMAKE to
do the build and there is no manifest. Troubles galore. And that is why it
was impossible for the IDE to create for me, as commanded, a working debug
version using the runtime DLLs. As a reminder, runtime debug DLLs are a
requirement of a 3rd-party product that is helpful in locating memory leaks,
which often arise in non-managed C++ projects. I'd really like to rewrite
the program in managed code, but I cannot do that now.

The solution was to call Microsoft. In discussions, jointly we decided the
best approach was to let Visual Studio 2008 create a brand new C++ console
project and feed it the old project source code (just the CPP and H files).
Immedately: problem solved!

The fly in the ointment was the unannounced default wide character set which
changed a clean compile to 350+ "errors." Eventually, I found the switch in
the IDE that turns Unicode off. All is now well. The 3rd party memory leak
finder works, too. But not under the 64-bit version of Vista. Well, you
can't have everything.
--
William McIlroy

"William McIlroy" wrote:

Here's the problem. I've been developing a C++ application since 2003 using
the default settings. Comes time to find all the memory leaks. I downloaded
a nifty package that won't work unless I use the debug library DLLs. I get
nothing but complaints from Visual Studio 2008. On <name-of-appProperty
Page I change Use of MFC to Shared DLL. This presents a problem. I am told
that the Linker is conflicted as follows: LINK : warning LNK4098: defaultlib
'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library. Oh my.
I told the IDE to do a debug compile and link. Apparently not all necessary
changes happened automagically. However, the build succeeded. Upon launch,
the loader complains as follows: This application has failed to start
because mfc90d.dll was not found. Re-installing the application may fix this
problem. Or --- it may not. Further fooling around produces complaints
about a manifest that either does not exist or contains nonsense. Question:
Is there a quick and easy way to shift from Standard Windows Libraries to DLL
Debug Mode that doesn't involve poke and hope?
--
William McIlroy