I'm trying to create a plugin for a program. The program works by loading your plugin DLL and executing specifically named functions within that DLL. Pretty standard stuff. However, I'd like to create my plugin in C# (and I am a bit of newbie). My question is, can I export regular C like functions from C#? or How do I easily create a stub to do that?
So far Google has not been helpful.
No, C# DLLs are managed meaning you need the CLR loaded in order for the computer to understand it. You might be able to use a normal C++ project, add C++/CLI to it (project settings), consume the C# DLL with it, then write basic C exported function that wrap around it.
That would be the first thing that I would try.
Hello,
You can't create Native DLLs using C# or any .Net framework language. The .Net framework can however use Native DLLs using P/Invoke.
It's not practical writing a native DLL in C# anyway. You'd be better off writing the DLL in C or C++ instead.
If you're going to make the final program in a .Net framework language (Managed C++, C#, .Net), then you can make the DLL in C#, otherwise don't.
To the op:
I do custom Add-in development for a package that uses old COM interop assemblies. We wanted to use c#, but since it depends so heavily on late-binding, we have to wind up using vb.net, and build the interfacing class as a COM-interop class. Once you get over that hurdle, you're usually pretty much golden. All of the supporting libs outside of the "interface" library are done in C#, so it's less work when the new version of the base application premiere's shortly.
Would love to hear what you are programming Add-ins for, so if there are any tips and/or tricks that we could assist you with, we can do so as you go forward.
If you use Visual C++, you can create a native dll that wraps functionality written in a .NET dll. If you know C++ at all (or if you are a quick learner), it will be fairly simply to write a C++ shim dll that calls out the functions you implement in a C# assembly.
But, you can't do it using only C#.
You can write an assembly/dll in C++/CLI that exposes functions in as standard DLL exports. You could then use these as a proxy for methods in a C# assembly if you want.
However, this doesn't mean it is a good idea. Forcing the CLR to load into a process is a pretty drastic step, and one that a plug-in author should not force on its host.
For example, Microsoft strongly recommeds that shell extension authors (ie. plug-in code for Windows Explorer) do not write those plug-ins (via COM) in .NET, because they don't want the CLR loaded into such a critical applicatoin.
It is possible (though unlikely) that the application will want to load the CLR itself and some point, and if a plug-in has already loaded a given version then this may produce versioning problems. Also the CLR can not be unloaded from a process, whereas the host application may expect to be able to unload plug-ins.
Hey everyone,
I managed to get what I wanted by following a fairly convoluted set of steps:
On the C# side:
Then I created an MFC DLL exposing the functions that I needed to export for the plugin interface. Then using the #import directive in my C++ code to load in the previously mentioned tlb file. That generates a stub so I can easily call into my C# code from C++ via COM.
The result appears to work perfectly and the performance is instantaneous (this is a bit surprising, I assumed the CLR loading overhead would be noticeable).
Loading the CLR into this particular application isn't really a problem but I am concerned about versioning issues with other plugins. Is this really a concern when I doing this all through COM?
I import the tlb type library in Delphi7, but the component only have the class BUT with out any method. the usless class.
What am I miss? some body have a c# projet to compare and find out where are the diferences