API Delegates might need a different attribute

[PeterRook]

I have the same motivation as you for creating a more complete managed AllJoyn API than that of Windows.Devices.AllJoyn. I started with having a look at the AllJoyn 14.06.00 C# Unity implementation and , of course, your implementation. As a test case, I do not use a sample like you do, but I started implementing the unit tests in the AllJoyn 15.09.00 core (C++) implementation. I have not tested the AboutListener part yet, but start with the BusListener. I really got stuck! Luckily, In the C# Unity stuff I found that (the structure containing) callbacks need pinning to make sure the garbage collector does not move them around. Apart from that I had to define the delegates with the UnmanagedFunctionPointer with parameter CallingConvention.StdCall!!! I saw your API uses CallingConvention.CDecl., so you might run in the same problems. I am no expert in P/Invoke, but thought this might help you in your efforts! By the way, I am writing my API in VB, since this is my 'native' language.

[dotMorten]

AFAIK the callbacks are being pinned, and event fires fine with either calling convention.

I did receive this tip recently, hinting at that we need to recompile the library with the cdecl convention.

the public 15.09a sources they have the calling convention set as stdcall just as they do in msajapi.dll If you don't change that to cdecl, you can expect random problems particularly with x64 if you call any of the variadic functions like alljoyn_msgarg_get.

Currently I'm mostly struggling with getting some of the string parameters out, like this one: alljoyn_msgarg_signature which supposedly is supposed to be done with a string builder:

        [DllImport(Constants.DLL_IMPORT_TARGET, CharSet = CharSet.Ansi)]
        internal static extern UIntPtr alljoyn_msgarg_signature(IntPtr arg,
             [MarshalAs(UnmanagedType.LPStr)][Out] System.Text.StringBuilder str, UIntPtr buf);

Note: This isn't currently what is in the generated code - working on this still.

[dotMorten]

Btw shouldn't matter if the library is written in C# or VB - you can still consume it from either language. However C# definitely has the best documentation and examples to go from, and the most experts to draw knowledge from, so if you're up for some C#, I would love to get some help making this library "work". For the most part right not it's just making the interop work as I go along and wrap the classes in "nicer" .NET classes. The nice thing about the code generator for the interop is "fix once, fix everywhere", and when a new AllJoyn version comes out, I just rerun the generator against the latest source code.

[PeterRook]

I really liked your API code generator, so I just the analyze part in my code. I changed to code generation part to the codedom generator! Your generator took a lot of tedious work out of my hands, and I completely agree with your fix once, fix everywhere principle. Good job!
I am not too convinced about my C# skills, so any code I would write in C# has to be thoroughly code-inspected. But if I can contribute, I gladly will. If this will lead to a more complete Alljoyn API, C# or not, I will surely use it!. After all, I want to use this in Home Automation software I am trying to create.
I am esp. interested in the security features of Alljoyn, something that is lacking or rudimentary in most Home Automation solutions I have seen so far (I had a thorough look at OpenHAB).

About the pinning: as I said I have focused on the BusListener functionality The callbacks are passed to Alljoyn using a structure. . Pinning was applied to that structure.

As mentioned earlier having a look at the Alljoyn 14.06.00 C# Unity implementation can also help.
In there the marshalling is done in code (so no attributes). I included MsgArg.cs, so you can have a look at how the alljoyn_msgarg_signature function is implemented/used
MsgArg.zip

[dotMorten]

Done a lot of work on msgarg and now have a working producer and consumer. I've also moved up to AllJoyn 16.04. The cdecl issue mentioned above turned out to be a non-issue