MC++ assembly can't find C++ runtime DLLs when used from ASP.NET

[Guest]

I've created a managed C++ assembly containing a managed class that is
instantiated from ASP.NET. The managed C++ assembly needs msvcp71.dll and
msvcr71.dll. When ASP.NET loads the assembly, it cannot locate the C++
runtime DLLs and hence throws an exception. I have placed the C++ runtime
DLLs in the same directory as the managed C++ assembly.

Does anyone know why ASP.NET can't find these C++ runtime DLLs?

If I place the C++ runtime DLLs in the System32 directory, everything works
fine, but I would really rather put these files in my application dir.

Thanks,
Clift Norris

 

[Tomas Restrepo \(MVP\)]

Hi Cliff,

I've created a managed C++ assembly containing a managed class that is
instantiated from ASP.NET. The managed C++ assembly needs msvcp71.dll and
msvcr71.dll. When ASP.NET loads the assembly, it cannot locate the C++
runtime DLLs and hence throws an exception. I have placed the C++ runtime
DLLs in the same directory as the managed C++ assembly.

Does anyone know why ASP.NET can't find these C++ runtime DLLs?

If I place the C++ runtime DLLs in the System32 directory, everything works
fine, but I would really rather put these files in my application dir.

Have you tried putting the directory you have the dlls in into the path for
the asp.net process?

 

[Guest]

Tomas,
Thanks for the reply!
All the DLLs, (my Assembly and the C++runtime DLLs) are in the
wwwroot/mywebsite/bin directory. I'm thinking that is surely in the ASP.NET
path, since that is where the .aspx code-behind DLL gets generated.
But it doesn't work there.

I can see that the Assembly is getting copied off to the TemporaryASP.NET
directory at runtime, and the C++ runtime DLLs are NOT getting copied there.

Any other ideas?
-Clift

 

[Tomas Restrepo \(MVP\)]

Hi Clift,

Tomas,
Thanks for the reply!
All the DLLs, (my Assembly and the C++runtime DLLs) are in the
wwwroot/mywebsite/bin directory. I'm thinking that is surely in the ASP.NET
path, since that is where the .aspx code-behind DLL gets generated.

Actually, that's not the path, that's just the appdomain's appbase directory
(or one of the directories in the private probing path)... managed
assemblies are loaded in a different way than unmanaged dlls.

What I meant was to add the directory to the PATH environment variable
(either at the machine level, or for the user the asp.net application is
running at, likely ASPNET)