C# Plugin Wrapper

[addilind]

Hi,
after I've seen many people here wanting to write their plugin in .Net, I've managed to find a good way to accomplish this. At first I've tried it myself creating the Chat-TTS-Plugin, and now I'm wrapping everything into a nice packet ready to develop plugins. A user named Skeletr0n is helping me doing all the nasty recoding work etc. As we want to deliver a clean solution, we've layed aside our own testing code to write a consistent package from the ground up, so the project is still at it's start. The newest version can be checked out at our svn-directory: http://ts3tts.zockprog.net/svn/TS3TTS/TS3Plugin/; but as I said before we're still working on it (so don't be sad if we haven't implemented the function you need right now - it'll follow). If there are any VB.Net programmers interested in this: I don't know how to use this project in VB.Net, if you want to use it you have to somehow transfer our work to VB.Net.
Special thanks go to Robert Giesecke for creating a VS Solution so you don't have to decompile to IL and recompile your whole project everytime you build it and to SpiritOffice for spotting a tiny mistake making the x86-plugins crash and his help improving the function/fixing mistakes.

[Stidor]

Very cool :-)

Will be keeping an eye on this project.

[t-master]

Looks very good, although there are some "bugs":
a) you need to put the unsafe keyword for the delegates using pointers (and therefor you need to compile it with the unsafe flag)
b) vs2010 has a problem that there's a property called "Configure" and a method called so (and the property isn't used anywhere)

And I have also a question:
when I compile my plugin, there is a myplugin.dll in the bin-folder, a myplugin.dll in the bin\x86 folder and one in the bin\x64 folder.
Do I have to distribute the ones in the subfolders or the one in the bin-folder?

[addilind]

@t-master:
a. the delegates are still in work, and, believe me or not, it is possible without the unsafe keyword and compiler flag
b. you need to distribute the dlls in the subfolders

[t-master]

Well, first vs2010 doesn't let me compile it without declaring those delegates unsafe and second don't you always have to use the unsafe-keyword when working with pointers in managed code?

[addilind]

First we haven't finished rewriting the delegate(which the program makes use of ONLY, take a closer look at Marshal.GetDelegateForFunctionPointer or at the Chat-TTS-Source, there I've enabled some functions) and so the stars making your compiler give you errors are only there because I've copy&pasted the C++ code and hadn't finished rewiting them.
And second, as stated above, you don't need to work with pointers. Btw the newest release should compile without errors (and the warnings have to be ignored as they are only about the struct which is to be filled by TS3-Client is never set to any value by .Net) if you comment out the unfinshed lines in TS3FunctionsCallback.cs, even if you can't call any TS3Function right now.

[TehTub]

Ok so i must be missing something...

I'm more used to working with my own systems so, how do I go about doing this? I cant seem to get past loading the plugin. Says that the Name Version ApiVersion and such functions are not present...

Confused I am.

[LiquidNL]

Couldn't figure out the getPluginPath function assuming it had been implemented correctly in the C# version.
Then I considered it may not be and took a closer look.
This is what it looked like:

TS3FunctionsCallback.cs

public delegate void getPluginPath (string path, IntPtr maxLen);

TS3Functions.cs

public static void getPluginPath(string path, IntPtr maxLen)
{
    //if (TS3FunctionsDirect.getCurrentServerConnectionHandlerID() != (uint)Errors.ERROR_ok)
    //{
    //    throw new Exception("TS3Functions.getCurrentServerConnectionHandlerID returned an error");
    //}
    TS3FunctionsDirect.getPluginPath(path, maxLen);
}

Took a peek in the example source (plugin.c) that came with the TS3 plugin SDK download...

#define PATH_BUFSIZE 512

char pluginPath[PATH_BUFSIZE];

ts3Functions.getPluginPath(pluginPath, PATH_BUFSIZE);

Seems to me the wrong parameter of the two was defined as the pointer.
Clearly the second parameter should be the number indicating buffer size itself and the first one is a pointer since strictly speaking at low level strings are always passed by pointer since arguments are pushed onto the stack typically as processor native sized integers (32 or 64 bit) prior to executing a CALL and changing stack frame.

Feel free to point out to me if using these functions as is was in fact possible using C#'s terribly vague high-level approaches in some way, but I seem to have missed something if that's the case.

Thus I made the following changes:

TS3FunctionsCallback.cs

public delegate void getPluginPath (IntPtr path, int maxLen);

TS3Functions.cs

public static void getPluginPath(IntPtr path, int maxLen)
{
    //if (TS3FunctionsDirect.getCurrentServerConnectionHandlerID() != (uint)Errors.ERROR_ok)
    //{
    //    throw new Exception("TS3Functions.getCurrentServerConnectionHandlerID returned an error");
    //}
    TS3FunctionsDirect.getPluginPath(path, maxLen);
}

And now it works just fine (without needing an unsafe context also) using something along these lines:

using System.Runtime.InteropServices;

const int PathBufferSize = 512;

IntPtr ptr = Marshal.AllocHGlobal(PathBufferSize);
TS3Functions.getPluginPath(ptr, PathBufferSize);
string PluginPath = Marshal.PtrToStringAnsi(ptr);
Marshal.FreeHGlobal(ptr);

This goes for getAppPath, getResourcesPath and getConfigPath as well.

[sventek]

With the most recent release (rc1) and the API version change this is no longer working for me. The following logic (working previously) just returns 0.

IntPtr result = IntPtr.Zero;
if (TS3FunctionsDirect.getClientVariableAsString(serverConnectionHandlerID, clientID, flag, ref result) != (uint)Errors.ERROR_ok)
            {
                throw new Exception("TS3Functions.getClientVariableAsString returned an error");
            }
Console.WriteLine(result);  // Only outputs '0' instead of the pointer as it did previously

Looking through the sdk sample I could not find anything that appears to have changed with this. Anyone have any ideas?