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.
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.
i want to import some C++ unmanaged dlls into my windows phone app. can i do this ?? while debugging the dll not found exception thrown. can anyone help me to where do i place my those dependency dlls .
thank you ...
It depends on the DLL. If the DLL is built using only API available to Windows Runtime apps then you can use it. See Win32 and COM for Windows Runtime apps on MSDN for a list of the available API. You won't be able to use a DLL built for a desktop system (you cannot run x86 or x64 on ARM) but will need a specific phone build.
To use it you will need to include it in your appx package. In Visual Studio's Solution Explorer add the DLL to your project and edit its properties to mark its Build Action as Content. When you build the app check to make sure it is in the appx directory. That will deploy the DLL with the app so it is available at runtime.
For me it was due to having WIC code in my App and/or calling CoCreateInstance in a windows phone environment ( on PC it works flawlessly though )
I have a C++ (Native code) DLL project developed for iOS and Android. I would like to port it to a C++ DLL (Universal Apps) to be consumed by a C# Universal Store Application. The code isn't HW dependent.
As a first step, before moving all the code, I created a small test solution as follows:
I created a C++ DLL (Universal Apps), myDll, that has a C++ Add1(int, int) function.
I created a C++ WinRT component (Universal Apps) that has C++ Add2(int, int) function.
I created a C# Universal Application, myApp, that calls Add2 which calls Add1.
Compilation passes OK, however when I run myApp the application crashes and report that myDll wasn't
loaded.
My questions are:
Is the scenario I described above possible? And If so, what can be the problem causing myApp to crash?
Is there a better way for me to port the iOS/Android C++ code to be consumed in a C# Universal Application?
Thx
1) Like Hans, my first guess is that you're not including the Dll in the apps package. If it's not deployed in the package it isn't available to be loaded. Since you can't add a reference to the DLL you'll need to add it explicitly:
Add the files to the project, open the files' properties in the Solution Explorer window, and mark them as content to be included in the app package.
Check that out is actually in the appx dir after you deploy.
2) That's probably the easiest. You could also include just the Dll and pinvoke. Either way you'll need to make sure the dll is valid for Windows Store apps
I have a .net solution with a C# project and a C++ project. The C++ project is an automation server (.exe). The C# project references an ActiveX interface produced by the C++ project (.tlb or registered interface on the machine). This works great on a development machine as I am registering the .tlb using regtlibv12.exe in a post build event in the C++ project. On the build machine, this fails because the service that runs the builds does not have rights to update the registry.
Is it typical to have the service that runs automated builds run as an administrator? Is there another preferred way to do this?
I also read that regtlibv12.exe is not always installed. Is there another way that is preferred to register a .tlb?
In a C# project just check if C++ application (automation server) is running and run it if not.
Then automation server (.exe) will register all available CLSID's in a system
I found no other way to register the type library in the build process other than using regtlibv12.exe. I had to make sure the automated build service is an administrator and everything works.
Here's the setup:
I've got a shared library (c++ with extern "C" methods) I've compiled in linux and created a library.so file.
I've used Mono Develop on the same box (Ubuntu) and was able to DLLImport("library.so") and access my extern functions no problem.
The problem comes in when I copied that .so file to a windows machine (Win7) and I try to do the same thing, but this time running Mono under windows with MonoDevelop.
I get a System.BadImageFormatException. I've tried doing a "./" before the library.so file, but nothing helps. I've checked and double checked that it's looking at the right directory and it is.
Is there something big I'm missing why I can't access this .so file under Windows/Mono?
You can't use a .so elf binary on Windows for your native code. You need to recompile it into a native binary supported by Windows (namely a .dll).
I suggest you read our wiki page about cross platform interop between managed an unmanaged code.
The problem is that the Linux SO is not a valid windows image. You will need to compile the C++ code under windows as a DLL and export the method so that you can call it using p/Invoke.
C/C++ is portable (mostly) at the source level, not at the binary level, so you cannot copy a Linux .so to Windows and expect that to be executable on the Windows platform. I am sure this raises the question, why can you copy your .NET/Mono dlls and exes from window to Linux and have them run, that is because the Mono CLI implmentation has code which is able to load the IL from the Windows image (PE) and then execute the loaded IL in the VM, so in this case it is not the native binary code that is being executed, but just the platform idependent IL which is loaded from the DLL/EXE container file.