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

  • Thread starter Thread starter Guest
  • Start date Start date
G

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
 
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.
Click to expand...

Have you tried putting the directory you have the dlls in into the path for
the asp.net process?
 
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
 
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.
Click to expand...

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)
 
Back
Top