tags:

views:

80

answers:

2

My company has login integration with GroupWise, and Exchange 5.5/2000+. The Exchange 5.5/GroupWise logic is done using wldap32.dll (win32), and so the login code is in a managed c++ class. When the configuration tool (or the backend service) tries to load the dll built off this managed c++ project on my XP development box, it works fine. On QA/Customer Windows 2003 boxes, a FileLoadException is thrown.

First off, this used to work fine. Secondly, I've validated the same working code on my box fails on the qa box.

How can I track down the cause of this exception?

A: 

Not to answer my own question, but support just updated the bug with the text following this paragraph. I'm still interested in thoughts on tracking down situations like this.

Resolved by downloading and installing the Visual C++ 2008 Redistributable Package for Windows on the IMS: http://www.microsoft.com/downloads/details.aspx?FamilyID=a5c84275-3b97-4ab7-a40d-3802b2af5fc2&DisplayLang=en

Jon Ediger
+1  A: 

Have you changed your development environment recently? In particular have you installed a service pack or new release of Visual Studio?

It appears you are linking against a C++ runtime that is not available on the client's server. You can use the Windows Event Viewer to identify the DLL failing to load, or if this shows nothing, use depends.exe to see what runtime DLLs are dependencies for your managed code.

Microsoft has moved to using side-by-side installation to handle "DLL hell", basically this allows multiple versions of a DLL to be installed (side-by-side) concurrently on a Windows installations and have applications load the correct version of the DLL at run-time. Recent releases of Visual Studio make use of this technology so I suspect this is the cause of your 'sudden' incompatibility.

Henk
Dependency walker (depends.exe) is your friend here, as well as just knowing what dependencies you have. That's the most common case.
Nick