I have a simple C# 4.5.1 x64 application which calls unmanaged dlls via a /clr C++ wrapper. App runs fine on my development machine. If I copy to Windows Server 2008 or Windows Server 2012 (with Framework 4.5.1 installed) I get an error that the wrapper won't load.
I have installed DependencyWalker on the deployment machine and I get this:
LoadLibraryExW("MyWrapper.dll", 0x000.., LOAD_WITH_ALTERED_SEARCH_PATH) called from ...
Loaded "MyWrapper.dll" at ... Successfully hooked module.
Loaded "XX.dll" at ... Successfully hooked module. (Dependency for MyWrapper.dll)
Loaded "YY.dll" at ... Successfully hooked module. (Dependency for MyWrapper.dll)
Unloaded "MyWrapper.dll"
Unloaded "XX.dll"
Unloaded "YY.dll"
LoadLibraryExW("MyWrapper.dll", 0x000.., LOAD_WITH_ALTERED_SEARCH_PATH) returned null. The specified module cannot be found.
Does anyone know why everything is loaded then unloaded and then cannot be found?
Make sure you have all the necessary redistributables (vcredist.exe) installed and you deploy a release build.
Any unmanaged c/c++ dll and also c++/cli dll links to msvcr. It is automatically installed with Visual Studio on the developer machine. It must be installed on the deployment machine together with the app. Make sure to redistribute the correct vcredist.exe version which corresponds to your version (and service pack) of VS. For vs2008 it resides in %ProgramFiles%\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages). Note: Dependency walker does not show missing dll if it is loaded using LoadModule() or methods are loaded using [DllImport("Sample.dll")] in c#. In that case, open the unmanaged dll directly in Dependency walker and check missing deps. Make sure, unmanaged dll is in search path of your app.
Related
I have a WPF application, which I build as a dll COM component and install using installshieldLE, however I have some issues with some dependent dlls, when running my COM client.
My WPF dll references two other C# dlls (A & B) which reside within the same VS2012 solution.
My WPF dll has the register for COM interop option checked and provides a COM interface for running the WPF GUI application.
I have a C COM client program, which tests the WPF application. The problem I am having is that I need to include some of dll_A's referenced dlls, (which is a third party graphics package) in the folder of the client program for the application to run successfully. I don't have to include dll_A or dll_B in the local client directory.
Also, there are other (C) dlls referenced by the COM server dll and included in the installation that do not need to be present in the client directory, so this is difficult to understand.
I assume that this is not a WPF question but simply a question about com server installation in relation to other referenced assemblies.
I have output some debug messages in the primary dlls that confirm that the dlls A&B, along with the main COM dll are being run from the installation location. But I get exceptions further down the line when the third party dlls are missing from the local client folder.
Can someone help me troubleshoot this problem please. I can run the client program successfully from the installation location and am therefore certain that all required assemblies and dlls are present.
Thanks.
It sounds like you're encountering issues related to the DLL load path. A client application can load your COM DLL, but your COM DLL can't load its own dependencies (or dependencies of dependencies, etc) even through the dependencies exist in the same folder as the COM DLL. Is this correct?
If so, I believe this problem can be solved with a call to the AddDllDirectory function -- just have your COM DLL call this before loading any of its dependencies and call RemoveDllDirectory when it's done. For more information, see the Remarks section of the documentation for LoadLibrary.
The problem was caused by one of the referenced dlls being compiled using .Net 4.0, whereas the others were compiled using .Net 4.0 client. Recompiling with .Net 4.0 Client resolved the problem.
The problem seemed to occur when executing the application as a registered com component, with the client being executed from a different location. If the offending dlls were copied to the client directory, everything runs fine.
My project is a plug in for a platform which is built in Native C++. And the plugin will reuse the current functionalities of an existing C# project, which is built upon .NET framework 4.0. We use the C++/CLR as the bridge to call C# codes. That is, the host application, built in unmanaged c++, calls into managed C++ dll which calls into C# dll.
The platform will run in one process and the plugin will run in another process.
And the way for the platform to find the plugin dll is that user will input a directory in the platform's user interface, thus the platform the load all plugin dlls in that directory into the plugin process.
This works well when my plugin folder is a local folder. However, when I set the plugin folder as the remote folder, and when I tried to instantiate a C# class from C++/CLR class, I got a FileNotFoundException, the detailed information is "Unknown URL protocol".
Our plugin project has both C++/CLR and C# codes, built into different dll files. In Debug mode, in the Visual Studio Modules view, it turns out that C++/CLR dlls are loaded while C# dll not loaded(both are in the app directory). And the exception happens when I tried to instantiate a managed class in C++/CLR codes, however, unfortunately there’s no stack call when I got the exception.
So how can I allow the host plugin process to load the remote C# dll properly?
After further investigation, we found the root cause is that the plugin's ApplicationBase is not set correctly. For some reason, if the folder is set as a remote folder, the platform passes the folder in Linux format rather than windows format, and our software is running on Windows only. This is why "FileNotFoundException" is thrown and it works well when my plugin folder is a local folder. We need to correct the ApplicationBase in windows path format.
I have a Windows Server 2008 Standard 64-bit box on which I run a test web site under IIS7.
My hosting provider has the same configuration than me yet my precious custom DLL is not honored?
Calls to my DLL (plain vanilla _CDECL Export Functions) are, well. "ignored".
No error message. Nothing. Zilch. I press the button in the middle of the page that should trigger the calls but nothing happens.
The DLL is located in C:\Windows\SysWOW64 on both machines.
That's the path used in my DllImport declaration.
The site is setup with ASP.NET v4 with Integrated Pipeline mode.
I checked for pesky dependencies and this DLL makes calls to Kernel32.dll and NTdll.dll, both of which who are sitting in C:\Windows\SysWOW64 next to my dear DLL.
No, I didn't have to register this DLL on my machine.
Any ideas would be appreciated.
We have a c# executable that loads a 32bit dll written in C++ which dynamically loads another 32bit dll (the first dll is a wrapper).
When this is built on a 32bit machine (with VS toolset v100) it all works correctly.
When it is built on a 64bit machine (with VS toolset v110) it runs on some machines, but on others it gets a FileNotFoundException on the wrapper dll. It works on some 64bit machines, fails on some and fails on at least one 32bit machine.
The failure happens in Assembly.LoadFrom, where the location comes from Assembly.GetExecutingAssembly().Location. The dll is in the same dir as the exe, which was build as x86.
If build on a 64bit machine to get a failing version, then I drop in a version of the wrapper dll built on a 32bit machine, it works properly (so it's not really a file not found problem, but rather a 'correct' file not found one).
Any ideas why this is failing? Is it the build machine, or the toolset? Or something else? Is there something I can set in the build to get it working properly (I'd like to continue building on a 64bit box)?
Do you have all dependency dlls installed on the client machines? Like VC Runtime, other libraries you depend on?
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?
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.
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