DLL no longer loads if built in Visual Studio 6

I'm working on a Visual Studio 2005 C++ .NET application. For networking, it uses a network protocol DLL built in Visual Studio 6. (The DLL developer swears by the older tool.)

At some point, the Visual Studio 6 project was updated to 2005 by another developer. The DLL was rebuilt, but it did not work. In any case, they decided to downgrade back to 6. I didn't realize this, so I loaded the 2005 .vcproj and built it. I'm not sure that was the trigger, but I suspect so.

Now, I cannot load the DLL on my machine if it was built in 6. Windows acts as if the .dll file doesn't exist. If I use the Visual Studio 2005 build product, it loads properly and runs but some functionality is brok开发者_JAVA百科en. The solution would be to upgrade and debug from 2005, but the other developer wants to continue with VS 6. However, it does work on other computers. All are running XP Professional SP3.

If I copy the program directory from a working installation to mine, .exe and .dll and all, it ceases to work. What could cause this?

I used the freeware ProcessExplorer program and verified that no other similar DLL is loaded, nor is any DLL loaded on the working installation's machine before I expect it to be.

The root cause of these type of problems is that you are mixing different runtime libraries: the VS6 dll uses msvcr60.dll while the VS2005 dll uses msvcr70.dll (that is, unless someone told VS2005 to compile against the VS6 framework but that's not likely). Typical problem example: the application allocates through msvcr70, passes that chunk of memory to the dll which deallocates using msvcr60, but that one uses a different heap. Bang.

The real solution here is to make everything (app and dlls) use the same runtime or in other words: upgrade to the recent VisualStudio version. It did not work is just a sign that the code is rather poorly written or uses outdated features; in both cases a healthy solution would be refactoring, instead of fiddling around with an almost ancient compiler. Ssuppose the other developer keeps insisting on using VS6, what will happen within 5/10/15 years? Does he have any real good reasons to stick with VS6?