statically and dynamically linking DLLs generated with different versions of Visual Studio

Question

Hi folks...here's the situation I'm looking for feedback on:

1. At work, one of my responsibilities is maintaining a couple of legacy apps, one of which we'll call "LegacyApp." It's always been compiled with VS 6.0. (And isn't touched much these days.)
2. It uses an API that provides access to some specialized hardware. This API is produced by another group at my company. We'll call this API "ControllerAPI." It's always been compiled with VS 6.0.
3. The developers of LegacyApp also wrote a wrapper DLL around ControllerAPI, which LegacyApp would use. We'll call this "WrapperAPI." I am responsible for maintaining this. It's always been compiled with VS 6.0.
4. WrapperAPI links statically against ControllerAPI.
5. LegacyApp inks dynamically against WrapperAPI.
6. With their next release, the group that makes ControllerAPI has begun compiling it with VS 2008, rather than VS 6.0, as had been their case up to this point.

So, here's my questions:

1. Since WrapperAPI is linked statically against ControllerAPI, I will need to compile WrapperApi with VS 2008? Is that correct? (I have done so already, was an easy step in this case.)
2. Since LegacyApp is linked dynamically against WrapperAPI, can I continue to compile LegacyApp in VS 6.0? If so, is there anything I'd need to do in my WrapperAPI compilation to ensure that is still the case. Or will I need to compile legacy app in VS 2008, which I'd rather not have to do at this time.

So, my question boils down to running Apps and Dlls with each other that have been compiled with different versions of Visual Studio, and whether or not it makes a difference if the various layers are linked statically or dynamically.

Thanks for any feedback

Answer 1

If the signatures of the functions exported from ControllerAPI and WrapperAPI have not changed, your bindings should be fine, static or dynamic.

However, if the types and objects used by the functions (input, output, return parameters) are dependent on an external library; then you may have issues.

For example, say if ControllerAPI allocates memory with one version of the C runtime, and WrapperAPI expects to be able to free it on it's own- then in this case they both need to be linked against the same version of the C runtime. If you recreated the project in VS2008 instead of importing and upgrading it- then your default compile targets and imported libraries may have changed. Similar issues can be observed in libraries created with types known to MFC, ATL, etc.

Unfortunately, you will need to check over these scenarios by hand, but if you can check off the following items, you should be fine. I should also note that these things would also be checked between any two given versions of Visual Studio and even any two builds against different compile targets or versions of the Platform SDK.

1. There are no cases where either DLL needs to be aware of the references linked in by the other DLL (memory / handle / resource allocation). However, it is ok if WrapperAPI accounts for items from ControllerAPI and deals with them appropriately (ex. ControllerAPI allocates something, WrapperAPI uses it, then hands it back to ControllerAPI for release/destruction).
2. No memory-alignment differences in structures used by both DLLs.
3. No changes in parameter types that are defined. Watch out for cases where one version declares a variable of a type that is 32 bit, but on recompile in VS2008 might be 64 bit under some compile targets (LONG).
4. No changes in calling convention (cdecl / pascal / etc.) for exported / imported DLL functions and any function parameter types.