I put a dll build in native C++ as a Universal DLL in my project directory of C# UWP app and setting content to copy always it was finding it and then the next day suddenly nothing, constantly getting:
"Unable to load DLL 'AVEngine.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)"
I am calling with:
[DllImport(DLLName, CallingConvention = CallingConvention.Cdecl)]
private static extern int OpenForProcessing();
I ensured the architecture and build config matches, I have also checked SDK versions (min/target versions), I'm stumped.
Use Dependency Walker to check dependencies of your AVEngine.dll. Probably some of them missing and because of it Dll cannot be loaded.
Better proper approach to expose old functionality to your modern C# UWP application is to wrap AVEngine.dll logic using a WinRT component. Then you can reference this component in UWP application. Article "Use Existing C++ Code in a Universal Windows Platform App" could be helpful.
Related
I have code written in ANSI C that I would like to use in C#. I have compiled the C code into a DLL and created C# wrapper classes to interop with the C code. The point of the wrapper is to simplify a users interaction with the underlying C code.
[DllImport(DLL, CharSet = CharSet.Ansi, CallingConvention = CallingConvention.Cdecl)]
private static extern void PrintHelloWorld();
public void PrintHelloWorldC()
{
PrintHelloWorld();
}
Above is a simplified example of what I have done so far. Now, I am trying to create a DLL from the C# wrapper classes I wrote. From here I could give both the DLLs created and someone would be able to interact with the C# based DLL to interact with the underlying C based DLL. Below is what I have done and what problem I am having.
I compile the C code into a DLL in Visual Studio 2019 with my Configuration=Release and Platform=Win32.
I compile my C# classes into a DLL in Visual Studio 2019 with my
Configuration=Release, Platform=Win32, and Platform Target as x86.
I create a new project and link my C# DLL and set Platform Target as x86.
I put my C DLL into the Debug folder of the project so that it is available to the C# DLL through the marshal directive.
I try to make a call into the C# DLL and below are the chain of events occurring.
Program calls C# DLL method PrintHelloWorldC() and is successful
Within PrintHelloWorldC() it tries to make a call to PrintHelloWorld();.
Following Error Occurs:
System.BadImageFormatException
HResult=0x8007000B
Message=An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
My research yielded that it was most likely a mismatch in Platform Target between the DLLs and Test Project, however, I have double checked all the configurations and they should all be compiled for x86.
Below is what additional testing I have done.
Created a C# Project, and wrote simple code to make a call directly into the C based DLL. This works fine.
It seems that as soon as I try to use the two DLLs on top of each other in another project I start facing issues.
Any help or guidance is appreciated. Thanks in advance!
I wrote a C++ Class Library in Visual Studio that just defines a function that invokes some Python:
#pragma once
#include <Python.h>
extern "C"
__declspec(dllexport)
void python()
{
Py_Initialize();
PyRun_SimpleString("2 + 2");
}
I made another project in the same solution that was a C# Blank Universal app. I tried to reference the DLL generated from the previous project I mentioned:
using System;
...
namespace StartupApp
{
...
sealed partial class App : Application
{
private const string CPPPythonInterfaceDLL = #"pathtodll";
[DllImport(CPPPythonInterfaceDLL, ExactSpelling = true, CallingConvention = CallingConvention.Cdecl)]
private static extern void python();
public static void Python()
{
python();
}
...
public App()
{
...
Python();
}
...
}
}
The app is in a Release configuration.
Whenever I try to run the app on my Local Machine, it always gives an error:
The program '[2272] StartupApp.exe' has exited with code -1073741790 (0xc0000022).
Activation of the Windows Store app 'ab6a8ef2-1fa8-4cc7-b7b3-fb7420af7dc3_7dk3a6v9mg4g6!App' failed with error 'The app didn't start'.
So my question is this: can I reference a C++ class library from a C# UWP project? Or does the security on UWP apps not allow this?
Or is it because of Python.h?
EDIT:
I built the project with a DLL project and a Runtime Component that wrapped it, and now I have this error:
An exception of type 'System
'System.DllNotFoundException' occurred in StartupApp.exe but was not handled in user code
Additional information: Unable to load DLL 'pathtodll': Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
I added a user to the DLL with the object name "Everyone" (I am not sure how else to give everyone permissions) but the error still comes up.
Firstly, UWP can't consume a legacy C++ dll just by DLLImport.
If you want to expose legacy c++ functions to C#, the first suggestion is to wrap that C++ logic using a WinRT component. Then you can reference this component in UWP application by following steps: adding it to the project, open the files' properties in the Solution Explorer window, and mark them as content to be included in the app package. This post would be helpful. This one provides more detailed steps.
If you want to PInvoke the dll, you can follow these steps (You can refer to this MSDN post):
Add win32 dll into your UWP project making sure to set its type as 'content'
Then in the proper cs file, using DllImport to PInvoke the dll.
There is one more thing: You need to make sure your Python dll is not using prohibited APIs in WinRT. You can check this by using /ZW compile option for the dll.
I want to use gsdll32.dll from Metro Style App c#. I load dll as follow:
[DllImport("gsdll32.dll", EntryPoint = "gsapi_delete_instance")]
private static extern void gsapi_delete_instance(IntPtr instance);
[DllImport("gsdll32.dll", EntryPoint = "gsapi_revision")]
private static extern int gsapi_revision(ref GS_Revision pGSRevisionInfo, int intLen);
[DllImport("gsdll32.dll", EntryPoint = "gsapi_set_stdio")]
private static extern int gsapi_set_stdio(IntPtr lngGSInstance, StdioCallBack gsdll_stdin, StdioCallBack gsdll_stdout, StdioCallBack gsdll_stderr);
But when I try to load dll not found exception occurs. I have already put it in Debug file. But it does work.
I reference from this link.
It is possible, but:
Was gsdll32.dll compiled against the WinRT SDK?
Does gsdll32.dll passes the App certification?
Did you include the dll in your package?
If the answer to any of those questions is "no", then your code will not work.
Build Ghostscript from source (PC version)
Microsoft Environment for WinRT
Ghostscript can be built in the form of a win32 DLL for use within a Windows Runtime application or Windows Runtime component. Building for WinRT requires use of Microsoft Visual Studio 2012. There is a solution file that can be loaded into VS 2012, in the directory winrt
The WinRT application or component should include iapi.h from gs/psi and link with gsdll32metro.lib from gs/debugbin or gs/releasebin. Also any app using ghostscript either directly or via a component should add gsdll32metro.dll as "content". This inclusion of the dll is necessary so that it will be packaged with the app. If one wishes to be able to run the debugger on ghostscript then gsdll32metro.pdb should also be added as content.
From the GhostScript 9.21 documentation
Yes, I do realize this question is half a decade old.
On my laptop, where I am developing the WPF application, everything works fine, debug and launch the .exe app.
My app uses a native DLL, for resolve the reference problem I add the DLL in bin/debug (release) folder. I access it using DllImport like this:
[DllImport("xptodll.dll", CallingConvention = CallingConvention.Cdecl)]
public static extern int LDA_About();
The problem is when I try to run the .exe app on another PC, when I need to access the DLL it crashes. I make a handle to log any unhandled exceptions and the following error appears:
Unable to load DLL ' xptodll.dll': The specified module could not be
found. Exception from HRESULT: 0x8007007E)
The bin/debug directory has xptodll.dll, and app files: .exe, .application, .exe.config, .exe.manifest, .pdb.
Maybe this is important, the xptodll.dll interacts with hardware, but why wouldn´t it have the same behaviour on both machines?
There is probably some further dependency that is failing. My guess is that xptodll.dll itself has dependencies on other libraries that are missing on the failing machine. The documentation of xptodll.dll should explain what dependencies are needed. If the documentation does not make it obvious what is missing, you can diagnose the problem yourself using Dependency Walker.
Another issue might be (beside all this "put the DLL in the correct location") that if the DLL was created with Visual Studio, eg. Visual Studio 2012, also the VCRedistributable for 64 bit must be installed (vcredist_x64.exe), which is profided by Visual Studio.
I have a C# winapp. I call a native .dll file (created in C++ by myself) from the C# app, and it works fine.
But when I copy my application (.exe and .dll files) to another machine, I get an error that says:
Unable to load DLL "c:\dllname.dll": The specified module could not be found. (Exception from HRESULT: 0x8007007E)
Here is the C# code:
class IsoMessageHelper
{
public const string ISO8583_DLL = "c:\\Hc8583.dll";
[DllImport(ISO8583_DLL, CallingConvention = CallingConvention.Cdecl)]
public static extern bool InitializationRq(...)
}
What should I do?
A common issue when deploying .Net applications that have native dependencies, is that the native dlls may be missing dependencies themselves on the target machines e.g. the correct version of the C runtime.
Use a tool such a Dependency Walker to analyze your native dll and determine if it has a missing dependency on the machine you have copied it too.
Try not to hard code any paths in the DllImport attribute parameter that specifies the name of the file. Then you should make usre the file is right besides the executable.
Something like this:
[DllImport("user32.dll", CharSet = CharSet.Unicode)]
Move the DLL to the root. If that works, then look at your attribute to determine why. You haven't posted any code, so I can't give you any specific reason.