Shergill

Hi all
I have developed a dll using VS2005. When I release that dll to my customers; I only release the one that was built under the 'release' mode. That particular release using 'Multi threaded Dll (/MD)' option for the CRT. The problem that I am running into is that my users who are using that DLL can not build their project under the 'debug' mode.

Is it true that since my DLL is 'release' mode; that anyone who uses it has to build their projects under 'release' mode. If so; what is the best way to release this dll so that the users are able to use the DLL but still build their projects under 'debug' mode.

Thanks!


Re: Visual C++ General Using Debug vs Release DLLs

Carl Daniel

If you're building a DLL that will be consumed by other users (i.e. your users are not end-users, they're other developers), then you should include both debug and release builds of your DLL in your distribution.

If you construct your DLL very carefully (e.g. like a COM object), then you can safely mix debug and release DLLs in a single executable. The exact details to make that work are esoteric, and have a significant impact on how you have to design the interface to your DLL. Post back if you'd like more information on that option.






Re: Visual C++ General Using Debug vs Release DLLs

Simple Samples

Shergill wrote:
Is it true that since my DLL is 'release' mode; that anyone who uses it has to build their projects under 'release' mode.

Not true. If it were true, then we would need two versions of Windows since most Windows API functions are in DLLs such as kernel32.dll. There are debug versions of Windows, but we are not required to use them to debug our applications. There are many other third-party applications that are provided only as release builds.






Re: Visual C++ General Using Debug vs Release DLLs

Simple Samples

Carl Daniel wrote:
If you construct your DLL very carefully (e.g. like a COM object), then you can safely mix debug and release DLLs in a single executable. The exact details to make that work are esoteric, and have a significant impact on how you have to design the interface to your DLL. Post back if you'd like more information on that option.

You are an MVP so I should assume you are correct, but that does not sound accurate to me. That is, the implication that mixing debug and release DLLs won't work unless we are careful simply as a result of mixing debug and release.






Re: Visual C++ General Using Debug vs Release DLLs

Holger Grund

Simple Samples wrote:

Carl Daniel wrote:
If you construct your DLL very carefully (e.g. like a COM object), then you can safely mix debug and release DLLs in a single executable. The exact details to make that work are esoteric, and have a significant impact on how you have to design the interface to your DLL. Post back if you'd like more information on that option.

You are an MVP so I should assume you are correct, but that does not sound accurate to me. That is, the implication that mixing debug and release DLLs won't work unless we are careful simply as a result of mixing debug and release.

It's not like release and debug builds are inherently incompatible. The exact same source code constructions should be compatible across debug & release. The problem here are # ifdef _DEBUG that cause binary incompatibilities (e.g. adding an additional member - which might cause spurious "Run-Time Check Failure #2" and other things )

STL containers and iterators are a good example for such types. There binary layout depends on _SECURE_SCL & _HAS_ITERATOR_DEBUGGING whose defaults in turn depend on _DEBUG.

It's usually a bad idea to have any MFC/ATL/STL defined types in your DLL interface contract, as it might tie consumers to a given version of a compiler toolchain with a fixed set of options. The DLL implementation may, of course, use whatever it deems appropriate internally.

-hg





Re: Visual C++ General Using Debug vs Release DLLs

Simple Samples

Holger Grund wrote:

It's not like release and debug builds are inherently incompatible. The exact same source code constructions should be compatible across debug & release. The problem here are # ifdef _DEBUG that cause binary incompatibilities (e.g. adding an additional member - which might cause spurious "Run-Time Check Failure #2" and other things )

I know you know I know about things like that.

Holger Grund wrote:
STL containers and iterators are a good example for such types. There binary layout depends on _SECURE_SCL & _HAS_ITERATOR_DEBUGGING whose defaults in turn depend on _DEBUG.

It's usually a bad idea to have any MFC/ATL/STL defined types in your DLL interface contract, as it might tie consumers to a given version of a compiler toolchain with a fixed set of options. The DLL implementation may, of course, use whatever it deems appropriate internally.

Certainly if a DLL can only be called from C++ then there are many potential problems unique to that. Am I correct that if all exported functions are extern "C" then there would be no problem that you describe with MFC/ATL/STL






Re: Visual C++ General Using Debug vs Release DLLs

crescens2k

Personally I try to keep debug and release builds seperate. The general idea is that the debug build is used for internal testing and finding user reported problems since extra information is included. The release build is used by the end users because it has gone through optimisations and generally runs better.

Of course there is, as mentioned above, no rule saying you can't mix debug and release. At the moment in my spare time I am writing a plugin library for a certain program. The program itself is not available to me as a debug build but there is no incompatibilities to worry about in how the API was constructed. The DLL is debug at the moment since I am testing it live, it is running well so I'm going to put the release version to work soon.

But I've read this before and I think it is quite accurate, debug and release are IDE concepts. To me, it is the names developers give different builds of programs, one containing more information and no optimisations to help debugging and one containing less information, checks and optimisation. The problem is, newer developers then get confused thinking that a debug build is something special.






Re: Visual C++ General Using Debug vs Release DLLs

Shergill

I am using a lot of STL (maps, lists, vectors, strings) in my DLL both as input parameter to function and output values. Could that be the reason for this issue




Re: Visual C++ General Using Debug vs Release DLLs

Simple Samples

You are implying that your DLL can be used only when called by C++ code; will you confirm explicitly that is true




Re: Visual C++ General Using Debug vs Release DLLs

Simple Samples

crescens2k wrote:
The problem is, newer developers then get confused thinking that a debug build is something special.

That is not a problem. A debug build is special; for example this question asks about critical differences of debug and release.