My project structure is as follow:
ASP.NET calling C# layer calling Managed C++ calling Native C++
(i'm trying to avoid using interop so this is why the managed c++ layer)
I wrote unit test that test the C# layer and it works fine.
When I try to run the asp.net page i'm getting: "Could not load file or assembly..." error.
I figured out that when i copy paste the Native C++ dll to "Temporary ASP.NET Files" (to the corresponding folder) the site works.
It seems that the Managed C++ code can find the Native C++ code only if it resides in the same folder - obviously I can't have my Native dll in the temp files.
Is there a way to set the Native in a global place(doesn't work with System32)?
Thanks for you comments.
It boils down to one option:
It is security issue
i set up the server it self with the code and it runs under the cassini, but when i publish it(to run under iis7) i'm getting "Could not load file or assembly ...."
i'm running IIS7 with ApplicationPoolIdentity , .net 4 Integrated
Thanks a lot,
Pini.
Well technically using Managed C++ in this way is a form of Interop between native / managed code, the commonly used alternatives being COM and P/Invoke. This is purely a terminology thing however, you would get the same issue using P/Invoke.
This blog article Loading C++ Assemblies in ASP.Net might help you out - In short you need to either:
Set the %PATH% environment variable before the Managed C++ assembly attempts to load your native C++ dll.
Use the DllImport attribute to set the dll path (not applicable in your case as you aren't using P/Invoke)
Manually load the C++ dll yourself (e.g. with LoadLibrary) before the Managed C++ assembly attempts to load your native C++ dll.
I suspect that installing your dll to Win SxS would also work, but I don't know enough about how this works to be sure.
You can set your path variable?
You set it by going to the Properties of "My computer"/"Computer (Windows-PauseBreak) and then clicking advanced settings. Click advanced. Environment variables. Modify "Path" under system variables as needed.
I had to flip a bool in the ApplicationPoolIdentity. One of the filed in the properties says "enable 32bit" and that did the trick :) the default is False
My server is 64bit and i build my native with 32bit.
Related
I have a WPF application which use pinvoke for calling a C++ method dll name as Project1.dll.when I am installing and using it on windows 7 it is working fine but on windows 8.1 it is giving “Unable to load DLL'C:\MyApp3\project1.dll':A dynamic link library(DLL) initialization routine failed.(Exception from HRESULT:0x8007045A)”. Project1.dll is placed in C:\MyApp3 folder. What is cause of this error can any one suggest?
That's a COM error code wrapping this Win32 error:
ERROR_DLL_INIT_FAILED 1114 (0x45A)
A dynamic link library (DLL) initialization routine failed.
It means the the DLL you loaded, or one of its dependencies returned FALSE from its DllMain.
You'll need to do some debugging to find out why. You might start by looking for DllMain in the DLL and any dependent DLLs.
I tried to use this way:
DLLImport a variable MFC dll
It works.
The problem is the C++ dll "myDLL" needs another DLL "XDLL",
I found that
the service current fodler when services started is the system32, not where the assemble are !!!
In this case, if I put "XDLL" in system32 it would work...
What I need is away to run it without copying anything to System32 or anyway else
Is it C# windows service issue ? or C++ ? what should I do ?
Thanks
If DLLs are specified by name only, that is without a complete path, then the Dynamic-Link Library Search Order comes into play.
There are lots of ifs and buts with this, but the bottom line is that if you put all the DLLs that your executable needs in the same directory as the executable, then the loader will be able to find the DLLs. That is the best practice because it requires no configuration, and you can be certain of which version of the DLL is to be loaded.
I have several Unmanaged C++ written lib files which I need to link to Managed C++ dll.
Then I need to invoke functions of this Managed C++ from C# application.
First step is OK - Managed C++ dll is created, I can see with ildasm that it exports functions I need. However when I try to call this function from my C#-written test app it says:
An unhandled exception of type 'System.IO.FileLoadException' occurred in Unknown Module.
A procedure imported by {MyManagedCPP.dll} could not be loaded.
This message goes from VS2010.
I made simple experiment - removed dependencies from all lib files in Managed C++ dll and rebuild it.
With this change it is OK - app starts, I can call functions of Managed C++ dll from C# test app.
Is it not possible by design to call managed c++ functions when dll has static linkage with lib files? Technical restriction? Or there is some workaround?
Thanks
You no doubt have an implicit dependency on a native DLL. It isn't clear from the question what DLL that might be. It could be msvcrxx.dll for example, a runtime support library for native C++ code. Which would be rather bad, you don't want to mix CRT versions. Such a missing DLL otherwise prevents the C++/CLI assembly from getting loaded, producing the FileLoadException.
If you have no idea what that DLL might be then you could use SysInternals' ProcMon utility. The trace will show you the program searching for the DLL and not finding it. If it is msvcrxx.dll then be sure to rebuild the .lib files using the same compiler version you used to build the C++/CLI assembly. If it is something else then make sure you copy that DLL to the build directory.
I'm trying to use the lame_enc.dll file from LAME in a C# project, but adding the thing seems impossible.
I keep getting an error that says that a reference could not be added and to please check if the is accessible, a valid assembly or COM component.
I have no C++ experience, though I would like to use the functionality. Right now I'm using Process from the .NET framework to call lame.exe and do stuff, but I'd like to know if there's another way.
You can only add managed assemblies as a reference to a managed project. What I normally do in this situation is to add it as ressource instead with "copy local" settings. That way the DLL is tied to and deployed with your project. I then use DllImport to manually get the APIs I need from that DLL.
You have to use P/Invoke to call unmanaged APIs from managed code.
To use an unmanaged dll (native C++) in C#, you have to use DllImport, not adding a reference to the project in visual studio (and that is why you get an error).
Here is the documentation of DllImport from the MSDN.
You will need to use PInvoke to call functions in your native lame dll. However, you will only be able to call functions that have been exported as "C" style.
You can use a tool like "PInvoke Interop Assistant" that will help you when working out the PInvoke call signatures to make calls from C# to your native dll:
http://clrinterop.codeplex.com/releases/view/14120
I've created and registered a managed COM library in C# on my development machine. I've successfully registered it and created a .tlb file with regasm, and successfully imported the tlb into a c++ console app used for testing.
My COM assembly is called "efcAPI.dll" and it references another assembly that has not been set up for COM or registered in anyway called "efcServerDiscovery.dll". This second dll contains some code used by my COM dll and exists in the same folder as efcAPI.dll.
Everything concerning loading the COM assembly works fine. I can create instances of my classes defined in the COM and call methods from them. However when I call certain methods that use the code defined in efcServerDiscovery.dll I get a _com_error which reports that it could not load file or assembly 'efcServerDiscovery'.
I've verified that everywhere on my hard drive where efcAPI.dll exists there's a copy of efcServerDiscovery.dll (which is just the location I built and registered efcAPI.dll from). I've also attempted to place efcAPI.dll and efcServerDiscovery.dll in the same directory as the c++ app with no success.
Any suggestions as to where the c++ app is looking for the assembly or how to discover where it's looking would be great!
Yes, this is a problem with COM components having non-COM dependencies. Windows doesn't consider the location of the COM DLL when it searches for dependent DLLs. The normal search rules are in effect, the folder that contains the EXE first, Windows directories, current working directory, PATH environment. The location of the COM server does not play a role.
Assuming you don't want to deploy to the EXE folder, none of these are good places to store your DLL, although plenty of installers made the desperation move of storing it in c:\windows\system32 or modify the system PATH environment variable.
One thing you could do is P/Invoke SetDllDirectory() in your C# code before running any code in the DLL. Using Assembly.GetExecutingAssembly().Location will do it. That is however not a safe thing to do though, it might alter the search rules for the app that uses your component.
The only real fix is to install the DLL in the Windows side-by-side cache (WinSxS) and to include a manifest in your C# executable. Given the state of the documentation, I can only wish you the best of luck.
In these situations i always start with Dependency Walker verifying that what & where its trying to load is what i think it is.
fuslogvw will tell you where the CLR is looking for assemblies
Or use GAC.
(here are your characters, stackoverflow)