I'm writing a "driver" for a program, the driver communicates with some devices on network. I already have C# software working with the devices, so the plan is to reuse code.
So the driver dll is really an interop between program and and already availible assemblies, it's written in C++/CLI. The program calls methods described in interface, the interop dll calls C# code, that is how I see it.
I implement methods to be called by program using #pragma unmanaged
DeviceSearch::DeviceSearch(IDeviceSearchHandler* handler):m_handler(handler)
{
ManagedWrapper mw;
mw.Init();
}
ManagedWrapper is implemented in managed code, obviously
void ManagedWrapper::Init()
{
//some code
}
However, the problem rises here. If the Init() is empty or calls methods/classes defined in C++, it's working ok. However, if I try to call the C# code (which is referenced using #using , where Facade.dll is the C# dll which performs some functions), I get access violation exception right when mw.Init() is called, not even within it.
Am I missing something really obvious I should do to make the interop work? Most information in the net just tells that it should "just work"
See if this helps:
According to How can i use a C# dll in a Win32 C++ project?
"Define an abstract interface class in your native C++ code, then create a concrete subclass inside the managed C++ DLL. Call into your C# objects in the method implementations.
Finally, export a factory function that will instantiate the implementation class and return a base-class pointer that your native code can use."
Related
I'm trying to write a DLL to access the C++-only method Windows.Devices.Bluetooth.BluetoothLEDevice.Close() from a C# app. I seem to be able to access the class, but Visual Studio will not build if I try to use that one method. It is shown in the member list that comes up as you type, and there is no Intellisense error, just the build error.
using namespace Windows::Devices::Bluetooth;
__declspec(dllexport) void CloseBleDeviceUnmanaged(BluetoothLEDevice^device)
{
if (device->ConnectionStatus == BluetoothConnectionStatus::Connected) //no complaints for a property
{
device->GetDeviceSelector(); //no complaints for a method either
device->Close(); //Error C2039 | 'Close': is not a member of 'Windows::Devices::Bluetooth::BluetoothLEDevice'
}
return;
}
How do I get this to at least build?
(edit: removed extraneous syntax problem as per Nico Zhu - MSFT's answer)
You don't need to do any of this to call Close from C# -- just put it in a using(...) block and it will dispose (close) the object for you automatically. If the lifetime of the objection doesn't lend itself well to a using block, you can simply call IDisposabe.Dispose() on it directly.
For the compiler error, this is documented in MSDN since you should never call Close from C++/CX:
Close methods aren't callable through Visual C++ component extensions (C++/CX) on Windows Runtime class instances where the class implemented IClosable. Instead, Visual C++ component extensions (C++/CX) code for runtime classes should call the destructor or set the last reference to null.
The parameter of CloseBleDeviceUnmanaged method is Value Type in your case. When you pass a parameter to the method. The parameter will generate a copy. And the original parameter has not been changed. Please pass the
reference type parameter like the follow.
void DevicesTool::CloseBleDeviceUnmanaged(Windows::Devices::Bluetooth::BluetoothLEDevice^device)
{
if (device->ConnectionStatus == BluetoothConnectionStatus::Connected)
{
device->GetDeviceSelector();
device->Close();
}
}
As for the Close method, I have reproduced the issue in my side(target platform version 16299), and I have report this to related team. Please pay attention to the thread update.
I've been working on a prototype code application that runs in C# and uses classes and functions from older C++ code (in the form of an imported DLL). The code requirement is to pass in a class object to the unmanaged C++ DLL (from C#) and have it be stored/modified for retrieval later by the C# application. Here's the code I have so far...
Simple C++ DLL Class:
EXPORT_DLL int init(MyInitParams *initparams);
C++ DLL Functions:
struct MyInitParams {
public:
int _np;
int _nm;
int type;
double *CV_Weight;}
in c# DLL
[DllImport("NEWUSEMPC", CallingConvention = CallingConvention.Cdecl, EntryPoint = "init")]
public static extern int init(InitParams parameters);
in c# class
class InitParams
{
public int _np;
public int _nm;
public int type;
public double[] CV_Weight;}
If you own the code of the c++ dll it would be a lot more convenient for you to include it in your solution, and create an interop between c# and c++ using managed c++ as a translation layer. Be aware, that the managed c++ layer should only do the translation of data and invoke the native method, and literally nothing else, because managed c++ is designed only as a bridge between the native and managed world.
You can also use mixed debugger to check out what is happening in both managed and unmanaged code in debug to take a look on the variables, so that you can see what's missing.
I personally would discourage the use of platform invoke instead of an interop class, because the latter is a lot cleaner and is easier to maintain later on.
I've had to jump through hoops, but I've almost managed to get ServiceStack working on iOS with Monotouch in my project. One runtime JIT exception is holding out:
System.ExecutionEngineException: Attempting to JIT compile method 'ServiceStack.Text.Json.JsonTypeSerializer:GetWriteFn<int> ()' while running with --aot-only.
The offending code is quite simple:
internal WriteObjectDelegate GetWriteFn<T>()
{
return JsonWriter<T>.WriteFn();
}
As a test, I modified the SS code to make the internal methods and types public and included the following in the startup code of my project (to actually get called).
var ick = ServiceStack.Text.Json.JsonWriter<int>.WriteFn();
var erk = ServiceStack.Text.Json.JsonTypeSerializer.Instance.GetWriteFn<int>();
This still doesn't alert the AOT for some reason, I get the exception when the code above executes! Is this because the generic parameter is a value type? Or is it because these are static classes and methods? How can I force Monotouch to AOT the methods above?
The SS code in question is in JsonTypeSerializer.cs and JsonWriter.Generic.cs at:
https://github.com/ServiceStack/ServiceStack.Text/tree/master/src/ServiceStack.Text/Json
There are some generic limitations in monotouch now. I think you should check your code to one of them.
We've created our own implementation of IXMLHttpRequest in a COM server (.exe) like so:
interface IMyXMLHttpRequest : IXMLHttpRequest {
...
};
coclass MyXMLHttpRequest {
[default] interface IMyXMLHttpRequest;
};
The problem is that when the build tries to register the COM server, we get the error "Error accessing the OLE registry". I debugged the registration code and it is failing in RegisterTypeLib. It looks like it is trying to pull in some of the type information relating to IXMLHttpRequest and (guessing here) can't change some registry keys related to that interface.
Is it just plain wrong to derive from IXMLHttpRequest? Should we be deriving from IDispatch instead and making our class use a dual interface? Or is it possible to derive from IXMLHttpRequest and we're just doing it wrong?
Update: I've uploaded a reproducible test case. I simply generated an ATL COM server using the Visual Studio wizard, and then I created a new interface derived from IXMLHttpRequest and a coclass that implements it. The registration fails as I described. If I change the interface to derive from IDispatch then it works fine. 100% reproducible on Windows 7 using Visual Studio 2010, running with elevated privileges.
error MSB3073: :VCEnd" exited with code -2147319780.
Just for the record, the error is 0x8002801C TYPE_E_REGISTRYACCESS "Error accessing the OLE registry."
As you already identified, the problem is around inheriting from IXMLHttpRequest interface which is defined outside of the type library. Extending an interface through inheritance is basically not a good idea in first place. Yes it is possible and it makes sense, however as soon as you approach putting this into a type library and having external references, you might be starting hitting weird issues.
As soon as you referenced IXMLHttpRequest, MIDL compiler is trying to put it into your type library as well. You can witness this by looking into intermediate build files:
It is not what you wanted, is it? You just wanted to reference it because it is already defined and hosted by another type library in msxml6.dll file in system32 (syswow64) directory.
The main question is why you want to inherit from IXMLHTTPRequest. Why you think a "normal" separate new IDispatch-derived interface is not good enough here? You can still implement IXMLHTTPRequest on this COM class as well. And you would not get into this trouble in first place then.
Anyway, the building problem is that on IDL the compiler sees definition of IXMLHTTPRequest coming from Windows SDK file directly.
You want to change your IDL file as follows:
import "oaidl.idl";
//import "ocidl.idl"; // <<--- Make direct IXMLHTTPRequest definition invisible
[
uuid(7397D60F-A428-42C5-B698-9FA850638074),
version(1.0),
]
library COMServerTestLib
{
importlib("stdole2.tlb");
importlib("msxml6.dll"); // <<--- Reference MSXML type library to import the right interface
In your C++ file you want to make the interface visible for C++ code:
#include "stdafx.h"
#include "resource.h"
#include <msxml6.h> // <<--- Re-add IXMLHTTPRequest definition for C++ code
#include "COMServerTest_i.h"
Your project is buildable again from here.
I have a MonoTouch app that dynamically instantiates a class (using Type.GetType()) at runtime. The class is in an assembly that is not referenced anywhere else in the app, so the MonoTouch static compiler thinks that the assembly isn't used and ignores the assembly when it compiles the app. If I add a reference to the class in the app, then the compiler includes the assembly and the call to Type.GetType() works fine:
MyAssembly a;
I would prefer to just tell the compiler to always include all the assemblies listed in the project's "References" when it compiles the app. Is this possible?
Thanks,
-Tom B.
You will have to change your project's Linker behavior from "Link all assemblies" to "Link SDK assemblies only".
The other solution, if you have the project code that assembly was created with, is to mark the class you want to use with the PreserveAttribute.
Were you able to figure this out yet? If not, I had a similar problem: Is there a way to force MonoDevelop to build/load an assembly?
As I understand it, that's just how the C# compiler works. I was able to get around this by adding a custom pre-build step that scripts a class into the referencing assembly that includes dummy references to the unreferenced assemblies, like so:
using System;
namespace MyNamespace
{
public static class Referencer
{
Type t;
//These lines are scripted one per class in the unreferenced assemblies
//You should only need one per assembly, but I don't think more hurts.
t = typeof(Namespace1.Class1);
t = typeof(Namespace2.Class2);
...
t = typeof(NamespaceN.ClassN);
}
}