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 )
Related
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 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 created a windows application and I have published it by publishing wizard.
Now I want to make it portable so that the end user does not need to install the application.
The application is very simple and the only dll it is referencing is office outlook interop.
Please let me know how can I make the application portable
You should be able to just copy the files in the bin folder and launch the app from there. This is called "XCOPY deployment", long marketed as one of the major benefits of .NET applications.
Just make sure that you set the properties on the Office reference so that the DLL is copied into the bin folder, too.
However, for this to work, the client machine must have the appropriate version of the .NET Framework installed. So it won't be truly portable unless you can control the configuration of all target machines, but at least it's a good start.
There's no need for the Winforms application to be installed. Just set Copy Local to true for your external referenced dlls. Build your project and copy all the files in /Bin/Release or /Bin/Debug (depending on project settings).
The only thing that has to be installed on the client's machine is the appropriate .Net Framework version.
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.
I have a WPF C# application that makes use of the InkAnalyzer class. On my development platform (Windows XP), I have added references to IACore.dll and IAWinFx.dll for the project before building the release.
However, when I tried to run this on a HP TouchSmart tablet PC (on Windows Vista), the application throws a "FileNotFoundException". Offending file name is IACore.dll.
Next, I selected the "Copy Local" option for both files, and rebuilt the application. However, once that is done, yet another file is not found. This time it is "IALoader.dll".
I realise that I must be missing something on the HP TouchSmart (on Windows Vista). Is the Vista laptop missing a SDK?
A Solution
I couldn't find IACore.msm anywhere on my SDK, and it's a recent SDK (XP Tablet PC SDK version 1.7), so I used Search to find the IALoader.dll, and manually copied it to my application's folder. No more complaints after that.
However, if there's a way for me to avoid bloating my application deployment with these files, it would be great. Thanks for your help, Jared!
Looks like this problem was encountered by a few other people as well. The basic problem is that the assembly is not installed in the GAC but in the Windows SDK directory. In order for your application to ensure it's loaded it must include the IACore.msm in the setup project or manually install the framework.
Full Thread:
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/719cbbde-013e-4165-b694-6a994d833352/