Can I create a regular windows DLL (for a plugin)

问题:

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.

回答1:

I managed to get what I wanted by following a fairly convoluted set of steps:

On the C# side:

1. I created a C# class with an interface
2. made it COM visible,
3. Signed the assembly with a strong name key file
4. Used gacutil to add the assembly to the GAC
5. Registered it with the REGASM tool and produced a tlb type library file.

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?

回答2:

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.

回答3:

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.

回答4:

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.

回答5:

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#.

回答6:

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.