1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

mix-up with DLL dependencies

Discussion in 'C++' started by ilyaz, Aug 28, 2010.

  1. ilyaz

    ilyaz New Member

    Joined:
    Aug 28, 2010
    Messages:
    1
    Likes Received:
    0
    Trophy Points:
    0
    I have a C# .NET application that was created a couple of years ago in VS 2005. It's a console app that depends on a bunch of DLLs. One of them is a managed C++ DLL. I just rebuilt the app (and all the DLLs) in VS2008. It throws a runtime exception. Part of the message reads:

    Could not load file or assembly ', Version=1.0.3887.18851, Culture=neutral, PublicKeyToken=null' or one of its dependencies. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1)

    where myManagedCppDLL is the above-mentioned managed C++ DLL.

    I am not sure what's going on here. Both the debug and the release versions of the app throw the same exception. This was not happening before when we were originally developing the app under VS2005.

    --- One strange fact that may or may not have something to do with this: After I "batch rebuild all", the Release folder of the app contains all the DLLs it depends on, directly or indirectly. Actually, the app depends on a .NET DLL that in turn depends on the managed C++ DLL. So I have three copies of the managed DLL:
    1. in the debug/release folder of the managed DLL
    2. in the debug/release folder of .NET DLL that depends on it
    3. in the debug/release folder of app
    I noticed that in the release location #1 I have the right DLL while in #2 and #3 I have the debug versions of the managed DLL instead of the release one.

    --- Another strange fact is that when I open the release version of the managed DLL in the Dependency Walker, all is well. When I open its debug version, it shows three MS DLLs as missing:
    1. MSVCR90D.dll
    2. MSVCP90D.dll
    3. MSVCM90D.dll

    What's going on here?

    Thanks much!
     

Share This Page