Is it possible to use a native C/C++ library with dot42? If so are there examples of how to do this? If not is this a planned feature?
Given the JNI implementation a native method such as the following:
#include <string.h>
#include <jni.h>
jstring Java_dllImportTest_MainActivity_Foo( JNIEnv* env, jobject thiz)
{
return (*env)->NewStringUTF(env, "Hello from dot42 JNI !");
}
The JNI tooling will compile this to a native library and put this in e.g. libs\armeabi.
Copy the libs folder to the root of your dot42 project and include the .so in your project. Next set the build action to NativeCodeLibrary:
Next declare the native method in your C# code using the DllImport attribute and call it like this:
using System;
using System.Runtime.InteropServices;
using Android.App;
using Android.Os;
using Android.Widget;
using Dot42;
using Dot42.Manifest;
[assembly: Application("DllImportTest")]
namespace DllImportTest
{
[Activity(Label ="DllImport MainActivity")]
public class MainActivity : Activity
{
protected override void OnCreate(Bundle savedInstance)
{
base.OnCreate(savedInstance);
SetContentView(R.Layouts.MainActivityLayout);
var textView = FindViewById<TextView>(R.Ids.label);
textView.Text = Foo();
}
[DllImport("dllImportTest")]
public static extern string Foo();
}
}
The loadLibrary call is generated by the dot42 compiler.
Related
I'm trying to write a c++/cli wrapper for IO Industries Core2 DVR, which will then be used by LabView. The company provided a SDK with with all the headers (written in c++) and boost library. I've managed to build a wrapper that builds and LabView is able to see the function through the .net pallet.
// ManagedProject.h
#pragma once
#include "core_api_helper.h"
#include "core_api.h"
using namespace System;
using namespace CoreApi;
namespace ManagedProject {
//Setup class
public ref class Setup
{
private:
public:
unsigned int initializeTest();
};
}
// This is the DLL Wrapper.
#include "stdafx.h"
#include "ManagedProject.h"
#include "core_api_helper.h"
#include "core_api.h"
#include "resource.h"
using namespace CoreApi;
using namespace Common;
using namespace ManagedProject;
//Global handles
//A handle to the Core Api
InstanceHandle g_hApi;
//A handle to the Core Api Device Collection
DeviceCollectionHandle g_hCoreDeviceCollection;
unsigned int Setup::initializeTest()
{
try
{
//Initialize the Core API (must be called before any other Core API functions)
//Returns a handle to the Core Api
g_hApi = Instance::initialize();
// get a collection of Core devices
g_hCoreDeviceCollection = g_hApi->deviceCollection();
unsigned int deviceCount = g_hCoreDeviceCollection->deviceCount();
return deviceCount;
}
catch (GeneralException& e)
{
e.what();
return 3;
}
}
However when I run LabView through Visual studio 2015 in debug mode I run into the problem below, and what is returned to LabView is the 3 from the catch block.
First break in debug mode (NULL ptr)
NOTE: InstanceHandle is a shared_ptr
As can be seen the variable is a NULL pointer, the same thing happens for the g_hCoreDeviceCollectoin as well. I think I need to Instantiate it with the new command but am a little unsure as InstanceHandle is a shared_ptr.
Any help would be much appreciated
The C++/CLI has great feature called mixed mode. You can uses both managed and native data types in the same code (in the same C++/CLI class). Try to use object from that SDK written in C++ directly in your wrapper.
I am working creating a hololens application using a native code dll based on c ++. The problem comes when I add it in the unity project (plugins / WSA / x86).
When generating the UWP solution in Visual Studio I get a failure of DllNotFound.
From what I have been able to read, it is necessary to create a UWP library to use it in my application. That library must contain my native code. The truth is that I'm not sure how to do that. Is there any way to stop my dll based on c ++ on a UWP dll ??
error: System.DllNotFoundException: Unable to load DLL 'nativoHololensPrueba.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E).
C++
SOURCE:
#include <iostream>
#include <stdio.h>
#include <memory>
#include "Header.h"
__declspec(dllexport)
int testo() {
return 10;
}
HEADER:
extern "C" {
__declspec(dllexport)
int testo();
}
c#
[DllImport("nativoHololensPrueba")]
public static extern int testo();
// Use this for initialization
public GameObject texto;
void Start () {
texto.GetComponent<TextMesh>().text = "Cambiando el nombre " + testo();
}
I also had this and I solved it by compiling the dll on ARM64 (or ARM) with /MT flag.
I want to use some code that executes a http-post, and because I'm not too familiar with c++ and what libraries you can use, and I am probably too dumb to get libcurl and curlpp to work, I found a link explaining how to use the .net version.
Alright so I created a class. Header File:
public ref class Element
{
public:
Element();
virtual ~Element();
void ExecuteCommand();
};
Class file:
#include "Element.h"
Element::Element()
{
}
Element::~Element()
{
Console::WriteLine("deletion");
}
void Element::ExecuteCommand(){
HttpWebRequest^ request = dynamic_cast<HttpWebRequest^>(WebRequest::Create("http://www.google.com"));
request->MaximumAutomaticRedirections = 4;
request->MaximumResponseHeadersLength = 4;
request->Credentials = gcnew NetworkCredential("username", "password", "domain");
HttpWebResponse^ response = dynamic_cast<HttpWebResponse^>(request->GetResponse());
Console::WriteLine("Content length is {0}", response->ContentLength);
Console::WriteLine("Content type is {0}", response->ContentType);
// Get the stream associated with the response.
Stream^ receiveStream = response->GetResponseStream();
// Pipes the stream to a higher level stream reader with the required encoding format.
StreamReader^ readStream = gcnew StreamReader(receiveStream, Encoding::UTF8);
Console::WriteLine("Response stream received.");
Console::WriteLine(readStream->ReadToEnd());
response->Close();
readStream->Close();
}
If I set the configuration type of this project to Application (exe), and create a new .cpp file where I create an Instance of this Element it works fine.
But my question is: Is it possible to create a .dll/.lib Library from this project and use it in a C++ project without CLI? (I don't want to use ^ for pointers :( )
Even if it's not possible, I have another problem.
When I link the library in a C++/CLI project. I get
unresolved token (06000001) Element::.ctor
unresolved token (06000002) Element::~Element
unresolved token (06000003) Element::ExecuteCommand
3 unresolved externals
the code for main.cpp in the second project is just the following:
#include <Element.h>
int main(){
return 0;
}
Thank you
As Hans Passant already stated: you must compile your C++/CLI code as Dynamic Library in order to be able to consume it from an unmanaged application. CLI/Managed code cannot run from/cannot reside in static libraries.
If you change the C++/CLI library target from Static library to Dynamic library you'll be able to compile successfully your unmanaged C++ application.
One thought from my side:
I think you'll be better if you use mixed mode C++/CLI DLLs to consume the managed functionality - you'll be able to free your consumer application completely from referencing the CLR.
The Header of such mixed mode Wrapper for your Element class would look like this:
#pragma once
#pragma unmanaged
#if defined(LIB_EXPORT)
#define DECLSPEC_CLASS __declspec(dllexport)
#else
#define DECLSPEC_CLASS __declspec(dllimport)
#endif
class ElementWrapperPrivate;
class __declspec(dllexport) ElementWrapper
{
private:
ElementWrapperPrivate* helper;
public:
ElementWrapper();
~ElementWrapper();
public:
void ExecuteCommand();
};
And the implementation would look like this:
#include "ElementWrapper.h"
#pragma managed
#include "Element.h"
#include <msclr\auto_gcroot.h>
using namespace System::Runtime::InteropServices;
class ElementWrapperPrivate
{
public:
msclr::auto_gcroot<Element^> elementInst; // For Managed-to-Unmanaged marshalling
};
ElementWrapper::ElementWrapper()
{
helper = new ElementWrapperPrivate();
helper->elementInst = gcnew Element();
}
ElementWrapper::~ElementWrapper()
{
delete helper;
}
void ElementWrapper::ExecuteCommand()
{
helper->elementInst->ExecuteCommand();
}
Then just compile your Element.cpp + ElementWrapper.cpp to a DLL and use the ElementWrapper.h in your unmanaged applications.
This question already has answers here:
Calling C++ dll from Java
(3 answers)
Closed 8 years ago.
I have one c++ dll which is previously used for c# application. now we want to use the same dll for java . i know that we can use JNI technology for this but the problem we have to use the same method signature we don't want to change the method singnature. please advise me.
One option is using JNA instead of JNI. It eliminates the need for the boilerplate native code. An example would look something like this...
import com.sun.jna.Library;
import com.sun.jna.Native;
public class Example {
public interface NativeMath extends Library {
public bool isPrime(int x);
}
public static void main(String[] args) {
int x = 83;
NativeMath nm = (NativeMath) Native.loadLibrary("nm", NativeMath.class);
System.out.println(x + " is prime: " + nm.isPrime(x));
}
}
You don't have to change the method signature, you simply add a native method which then calls the native C++ code. Here is a simple example:
public class Someclass
{
public native void thisCallsCMethod(Someparams);
}
Now create the JNI wrappers:
javac Someclass.java
javah Someclass
This will create a Someclass.h, then you create Someclass.cpp and include the .h in it.
At this point all you have to do is write the C/C++ code for thiCallsCMethod
In the .h you'll see a method signature that you have to implement. Something along the lines of:
#include "clibraryHeader.h"
using namespace clibraryNamespace;
JNIEXPORT void JNICALL thisCallsCMethod(JNIEnv *, someparameters)
{
cout<<"Yeah C code is being called"<<endl;
someCfunction();
}
Obviously you have to massage the parameters in the JNI call, but you can create some temporary variables, then copy back the values you get from the C calls into the incoming parameters (if they need to be returned) etc.
Maybe:
#include "clibraryHeader.h"
using namespace clibraryNamespace;
JNIEXPORT void JNICALL thisCallsCMethod(JNIEnv *, someparameters)
{
cout<<"Yeah C code is being called"<<endl;
Cstruct temp;
temp1.somevar = param1.getSomeVal()
someCfunction(temp);
}
I have 1 native c++ dll, CppApp, another project is managed c++, GatWayLibrary, with /clr
In GatewayLibrary, I called functions from native CppApp dll.
but I got unresolve token errors.
Here are my code snips:
CppApp.h
=========
#ifdef CPPAPP_EXPORTS
#define CPPAPP_API __declspec(dllexport)
#else
#define CPPAPP_API __declspec(dllimport)
#endif
class CPPAPP_API CppApp
{
public:
CppApp();
~CppApp();
ContextManager & contextMgr() { return m_rplContextMng; }
INativeListener* m_listener;
void registerListener(INativeListener* listener)
{
m_listener = listener;
}
...........
}
In separate project, GateWaylibrary, wrap the native dll as
#include "../CppApp/CppApp.h"
#include <vcclr.h>
using namespace System;
using namespace System::Runtime::InteropServices;
#pragma comment(lib, "CppApp.lib")
namespace GatewayLibrary{
//.net equvelant of the argument class
public ref class DotNetEventArg{
internal:
//contructor takes native version of argument to transform
DotNetEventArg(const NativeCPPArgs& args) {
....
...
}
the managed c++ has the linking errors as unresolved tokens for all the function calls from the native c++.
I did include the CppApp.lib as Additional Dependencies
and the directory.
Can anyone please help? many thanks ahead.
Edit:
here is of the place I called the native c++
`GatewayLibrary::EventGateway::EventGateway()
{
nativeCode_ = new CppApp();
//note; using 'this' in ctor is not a good practice
nativeListener_ = new NativeListenerImp(this);
//register native listener
nativeCode_->registerListener(nativeListener_);
}`