I'm building a Keygenerator application with .Net Maui (not blazor).
For this i use c#-Code in the MainPage.xaml.cs that calls a cpp .dll file and imports some methods.
The import looks like this:
[DllImport("W5R._Keygen.dll", CallingConvention = CallingConvention.StdCall)]
internal unsafe static extern void
SHA256_calc(byte* hash, void* input, ulong inputlen);
The .dll is in the same folder as the MainPage.xaml, App.xaml etc.
By changing some properties of the .dll (Build = content) the Debug version on the Windows Machine works fine and it works exactly as it should.
HOWEVER:
and this is the problem:
when I run the application on the android-emulator it loads the app just fine and as soon as i press a button that invokes the usage of the .dll my App Crashes and it just stopped working.
Beforehand I had the error ".system dll not found" which i fail to reproduce in the current moment.
Anyone knows how I use the .dll library? It's cpp code that i cannot access.
You can't use a dll on Linux / Android.
Dll are a windows thing and Linux has other formats for shared libraries.
see this Post
It seems there exists a wine release for Android, but I don't know how its used.
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 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.
Pretty much all the questions about this problem end up people trying to run 64 bit dll with 32 bit app, or 64 app - 32 dll. I have a diferent problem.
My delphi application is 32 bit, in visual studio i have set the target platform to x86. Using the unmanaged exports for DllExport funcionality.
Whenever i try to import the dll into my delphi application it shows me this error.
In a C# dll it looks like this
[DllExport("Open", CallingConvention = CallingConvention.Cdecl)]
public static void Open() {
MessageBox.Show("hello");
}
Inside delphi it looks like this
procedure Open(); cdecl; external 'mydll.dll';
When i run the app, it shows the error. Then i took another C# dll project made by another person, added a function just like the one i had in my own dll. Added the dll to the delphi app folder, ran the app and it was fine, i could call the Open();
I tried to see if there were any differences between my c# project and the other one and failed to see it. Everything looked similar.
Well, i started wondering what am i doing wrong. And i believe i have found the cause, sort of.
When i created a solution i picked Windows Forms Application (thinking that i need a form, which i will call from a dll later on), then went to properties and changed it to Class library, this was enough to compile it into a dll.
Then i figured i should try a different project type, i picked Class library project type this time. I quickly added same code as i had, compiled, moved dll to delphi app, and was surprised that it actually worked.
So my question is, WHY did it not work when i picked Windows Form Application and changed the type to dll? There was no difference in project files settings as far as i could see.
EDIT 1:
I have also figured a couple more things. The faulty solution (lets call it Solution A), as i said, was created by selecting Windows Forms (this creates a solution + project in one go).
Good solution (Solution B) was created by selecting Class library, again both the solution and project created all together.
If i delete the project from solution A, and add new project by selecting proper one (Class library) it will still compile a non working dll for me.
SO creating new solution (and selecting Class library) from scratch is a must for the dll to work.
Second thing i noticed were the difference in files that were generated once i compile the projects.
In a solution A i was getting a .dll, a .pdb and a RGiesecke.DllExport.Metadata.dll.
In a solution B i was getting a .dll, a .exp, a .lib and .pdb. No dllExport dll this time.
Both are DEBUG configurations.
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.