Building .dll for lower version of visual studio

Question

I'm using Visual Studio 2010 to build my DLL library.

And, other programmer who's using Visual Studio 2005 wants to use my DLL library. He can compile with my dll, but, when running his application, it just crashes with bad_alloc exception. I assume that's because of different CRT version.

When building my DLL library, I tried both dynamic linking of CRT(/MD) and static linking of CRT(/MT), but both failed.

So, can't I make DLL library that can be used by lower version of visual studio? If not, how I can I do that?

Answer 1

As far as I know you have to use only primitive types dll interface. it's because even in a same compiler memmory layout changes by only changeing compile flags, think of what would happen by changing compiler. and that could lead to a largescale undifined behavior.

and use the following format for your function interfaces:

extern "C" __declspec(dllexport) void doSomething(int input);

Answer 2

You can only export abstract base classes (containing at least one pure virtual function) with no data members for binary compatibility, I guess that was behind the question about your dll prototype. Here http://chadaustin.me/cppinterface.html is a good discussion on the issue.

Answer 3

Most easiest solution: give the other programmer the source code of your DLL and let him compile the DLL by himself against the old CRT. If that's not suitable (because you don't want to give the source code out of your hands, or your DLL does not compile with VC++ 2005), either you have to get a VC++ 2005 compiler, or the other one VC++ 2010.

Answer 4

If you have VS2005 installed on you machine, you can use the VS2010 new Platform Toolset feature to use the VS2005 compiler.

Its under Project Properties->General->Platform Toolset. VS100 is vs2010, VS90 goes for 2008 and (i think) VS80 is what you need (for 2005...).

AFAIK, trying to use different toolset built DLL will be harder (though possible, as you don't link with it).

Cheers

Answer 5

Most likely, you are using things (like C++ containers or types) that have changed between versions of VC++ compiler implementations, and passing these across DLL boundaries between DLLs built with different VC++ versions is likely to fail.

You need to build the DLL with that specific compiler (VC++ 8.0 for VS2005, VC++ 9.0 for 2008, VC++ 10.0 for 2010...) in order for the other programmer to use it. That, or he has to upgrade his Visual Studio to use the same version as you.

Answer 6

This is a fairly old problem and this is one of the reasons for COM. I would suggest you do the following -

1. Create an abstract base class and (aka interface) (say IExportedFunctionality) that exposes the methods that your currently exported class (say CExportedClass) offers and has a virtual destructor.
2. Dont export CExportedClass any more.
3. Derive CExportedClass from IExportedFunctionality and ensure all the methods are implemented.

4. Export 2 functions from your Dll named

   a. GetExportedClass which returns a pointer to a new instance of CExportedClass upcast to IExportedFunctionality*.
   b. FreeExportedClass which accepts a IExportedFunctionality* and deletes it.
   

Now all you need to do is provide the header file with the declaration of IExportedFunctionality. You can even do away with the lib file as your users can make use of LoadLibrary and GetProcAddress to call GetExportedClass and FreeExportedClass.

Note: IExportedFunctionality should have

1. Only pure virtual functions - since IExportedFunctionality is an interface not implementation.
2. Pure virtual destructor - so that doing a delete on a IExportedFunctionality* will translate into a call to CExportedClass's destructor
3. Do not have ANY data members in IExportedFunctionality (As user383522 pointed out binary layout of the class can vary across compilers and under different byte alignments)