Creating an NPAPI Plugin in C #

Question

Trying to create a CAP NPAPI plugin I found a tutorial that describes that your DLL needs to implement a number of methods, such as NP_GetEntryPoints , NP_Initialize and NPP_New along with a number of others.

However, I want to understand if I can simply reflect these method names and build equivalent data structures, as described in the article (e.g. _NPPluginFuncs ) in C #, and everything will work?

Can someone please be kind enough to give some recommendations? Is it possible to build an NPAPI plugin in C #, and if so, what are the main steps?

Answer 1

As stated in the documentation:

The NPAPI browser plugin is basically just a DLL with multiple entry points

This means that you need to export some function from a regular DLL, which is usually done in C / C ++. Unfortunately, it is not possible to show any entry point from a simple C # dll, but look at this answer , with some effort, you can apparently fool some export with some type of message creation tool.

In any case, do not expect the transfer of too complex data structures from / to the plugin interfaces, this will be a pain. If you are interested in doing more research, the key word to use is "reverse P / Invoke," similar to direct P / Invoke, which calls a regular dll from a controlled world.

The reason C # dll cannot set "entry points" directly is because the entry point actually represents only some address inside the dll pool in order to immediately get executable assembly code. C # dlls are different types of beasts: they are just files containing an IL that is compiled "Just In Time", and, indeed, AFAIK has to compile such compilation with some OS tricks . This is the reason why the reverse P / Invoke is not stellar at all.

Answer 2

As Georg Fritsche notes in his comment:

NPAPI plugins are basically DLL files with several required C-export

and there is no built-in way to export functions (in the sense of C-export) from an assembly written in C #.

Some of your options are:

• A mixed C ++ assembly that can directly export functions. This may have implications for hosting the CLR in the plugin host process.
• The small native DLL that hosts the export then uses COM interaction to delegate to the C # assembly containing the plugin functionality. The "official" way to do the so-called "reverse p / invoke".
• an intriguing project that handles your fully-managed assembly, turning static methods marked with a special attribute into named export functions. (I have no connection with this project, I came across it after I was wondering if anyone had improved on COM interoperability).