My bos, who is not a CS guy, asked me to develop a dll in c# for him.
further investigation on my side reveal that the dll should be in cdecl conventions.
If I'll take this project it will be my first dll development.
browsing through google tell me this is possible, but before I tell the bos
I can do it, I wanted to get your advice regarding this issue.
(lets assume nor time or code-quality are the main issue, but it needs to be done)
Any comments regarding such possibility would be much appreciated.
It sounds like you are looking for unmanaged function exports. There's no out-of-the box way to achieve that in C#. You can use Robert Giesecke's Unmanaged Exports. This performs some magic during compilation to modify the emitted IL to allow unmanaged exports.
The officially supported way to export unmanaged functions from a .net DLL is to make a mixed mode C++/CLI assembly.
Yet another way to export your functionality to unmanaged code is to expose a COM server from your C# code.
Related
In VS C/C++ you could use extern "C" __declspec(dllexport) -function declaration-.
How do I accomplish this in a C# dll? Is there C# code equivalent to the above code?
Edit: More info
I am trying to create an add in for Notepad++ and I want to use C#, but the common way I've seen so far is to use legacy C++ code with the above call to export a few of the functions that Notepad++ expects to import and call. There is an example app using C#, but this still requires a loader DLL, which I assume from the comments/answers below is the only way for C#.
Unmanaged Exports =>
https://sites.google.com/site/robertgiesecke/Home/uploads/unmanagedexports
DLLExport => https://github.com/3F/DllExport
How does it work?
Create a new classlibrary or proceed with an existing one.
Then add the UnmanagedExports Nuget package.
This is pretty much all setup that is required.
Now you can write any kind of static method, decorate it with [DllExport] and use it from native code.
It works just like DllImport, so you can customize the marshalling of parameters/result with MarshalAsAttribute.
During compilation, my task will modify the IL to add the required exports...
I've seen people do this before, but it required ildasm, adding the MSIL .export directive, and then reassembling. A program named dll_tool can do these steps for you.
If you want to build a mixed-mode DLL with both native and managed exports, you should be using C++/CLI, which is specially designed for this purpose.
Yes, it is possible to export functions from a C# dll in much the same way that C++ does it! You need a little help from an add-in Unmanaged Exports (DllExport for .Net) that facilitates this process, or from a similar method such as Exporting functions in C#/VB.NET to native code.
Please see Code to Export C# DLL to Metatrader Build 600+ for a working example using Robert Giesecke's C# Project Template for Unmanaged Exports to export a C# dll to a legacy application (Metatrader) that has a great deal of similarity to C++.
Additionally, you might find Native and .NET Interopability interesting though it is mostly geared toward accessing native code from within .NET rather than the other way around.
No, you cannot do that in the same sense as you do in C and C++.
But you can create COM API to achieve that which then you can use in C and C++ code.
See these articles
C# Classes as COM Objects
Calling Managed .NET C# COM Objects from Unmanaged C++ Code
COM Interop Part 1: C# Client Tutorial
Good day,
I want to take an existing C# project and wrap functions into a C++/CLI DLL. I need to be able to read this DLL from VB 6. I choose this route because I won't have to register a .net DLL in order to use it with VB 6. Frankly I have no experience with this kind of thing so I would greatly appreciate a good example. I know there are plenty of similar questions like this but I haven't been able to find anything simple enough for me to understand.
This is a fairly unwise route to pursue, making C# code [ComVisible] is pretty trivial and Regasm.exe should not scare you. The usual mistake with Regasm is to forget to use its /codebase option on your dev machine.
If you insist on not taking advantage of this then you'll need to find a way to get the CLR loaded yourself so it can execute your C++/CLI and C# code. There are three basic ways to do so. You've written off COM interop and hosting the CLR yourself isn't very practical if the host app is VB6. You however can take advantage of the C++/CLI compiler's ability to generate unmanaged DLL entrypoint stubs that load the CLR for you and switches to managed code execution. Do so by writing a static function that you decorate with __declspec(dllexport). The technique is shown in this answer. Beware that it isn't particularly performant and you'll have to live with the restrictions imposed by the VB6 Declare statement.
Also check this post-processing tool that can inject these stubs directly into a C# assembly. Not sure how reliable it is, I haven't used it myself.
Be a man and make that DLL under a couple of different compilation/linking/function-call-protocol configurations. Then go ahead and try a couple of different referencing configurations in your VB6 project. Post what works. Contribute, go forth!
Take a look at Export Managed Code as Unmanaged
and C# Project Template for Unmanaged Exports
Attempting to build a C# NPAPI plugin I have found a tutorial which 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 what I want to understand is if I can simply mirror these method names and construct equivalent datastructures as described in the article (like _NPPluginFuncs) in C# and everything will work?
Could someone please be kind enough to provide some guidance? Is it possible to build a NPAPI plugin in C# and if so what are the basic steps involved?
As stated in the documentation:
A NPAPI browser plugin is, at it’s core, simply a DLL with a few specific entry points
That means you need to export some function from a regular dll, that is done usually in C/C++. Unfortunately it is not possible to expose any entry point from a plain C# dll, but look at this answer, with some effort it appear to be possible to trick some export by some sort of post build tool.
In any case don't expect to pass too much complicated data structures from/to the plugin interfaces, it will be a pain. If you are interested in doing more research the keywork to use is "reverse P/Invoke", in analogy with direct P/Invoke that is calling regular dll from managed world.
The reason a C# dll can't expose directly "entry points" is that entry point are actually just some address inside the dll poiting to some assembly code immediately executable. C# dll are different kind of beast: they are just files containing IL that is compiled "Just In Time" and indeed such compilation is forced AFAIK with some OS tricks. This is the reason reverse P/Invoke is not starightforward at all.
As Georg Fritzsche says in his comment:
NPAPI plugins are basically DLLs with a few required C-exports
and there is no built-in way to export functions (in the C-export sense) from an assembly written in C#.
Some of your options are:
A mixed-mode C++ assembly which can export the functions directly. This could have implications for hosting the CLR in your plugin's host process.
A small native DLL which hosts the exports, then uses COM interop to delegate to a C# assembly containing the plugin functionality. The "official" way to do so-called "reverse p/invoke".
An intriguing project which post-processes your fully-managed assembly, turning static methods marked with a custom attribute into named function exports. (I have no affiliation with this project; I stumbled across it after I got to wondering whether anyone had improved on the COM interop way of doing things.)
I'm a Linux C++ developer, and I need to write C++ dlls for windows, which is to be used in C# applications.
The problem is importing the DLLs into C#, which I have no idea how to do it. In my friends' project its probable that any kind of unmanaged dll will be used, and I'm charge of doing this :-D
I need to import all objects and functions in the DLL, and my search has led me to nothing more than DllImport and so.
Thanks so much for helps.
You can use C++/CLI as a wrapper for your unmanaged C++.For more info on C++/CLI and what it does you can use this link
http://www.functionx.com/cppcli
You can have a quick look at this
http://www.codeproject.com/Articles/19354/Quick-C-CLI-Learn-C-CLI-in-less-than-10-minutes#A8
you want DllImport
There's a bunch of info here :-
http://msdn.microsoft.com/en-us/library/aa288468(v=vs.71).aspx
and lots lots more all over google, and many stackoverflow questions related to DllImport
There are many ways to go about this. You can write a CLR dll in C++ which puts an interface that C# can directly "talk" to. This is a nice option cause you can keep native C++ still and not have all of your code be CLR based.
Do some searches for C++/CLI
You can also use dllimport and friends and create a standard dll.
Have you thought to keep the Dll's in C++ (port then recompiled under VS.NET) less effort than a C# port.
I have in the past made a shared memory DLL to allow LabVIEW (Windows7) and a Winforms C#.NET appl. to share data storage via this dll.
Take a look at this tutorial. It shows two methods for accomplishing what you want: How to Marshal a C++ Class
I´m really in the need of getting a deeper understanding of how to set up things right to get an elegant interaction between my C++ and C# code bases.
What I want to achieve is an in-game editor written in C# for my game engine (C++/DX). For doing so I let VS build my engine as a C++ dll with some additional functions (unmanaged code) to access the required functionality of my engine from the C# editor code base. So far so good.
The first thing which is bugging me is that I´ve to build the dll with CLR support. Otherwise C# does not accept the dll for some reason. It doesn´t even allow me to add it to the resources ("A reference to 'C:\Users...\frame_work\Test\frame_workd.dll' could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component.").
And when I build the dll with CLR support and add it to the references in C# ,re-build without CLR support, start my editor and make a function call from the dll then I get an Exception HRESULT: 0x8007007E. I searched for it but the only thing I found had to do with dependencies but that doesn´t fit to the alert I get when adding the dll to the resources.
The other point is that I always have to switch the configuration type between application (.exe) and dll. in VS C++ depending on whether I want to run my engine directly or from the editor and every time the complete project is build completely new.
So, could someone explain to me how to organize this the right way? And what could be a possible reason why C# wants the dll to be compiled with CLR support?
Thank you guys/girls.
There are two ways to deal with this.
Either you make your C++ code provide an API which has a fully compliant COM object. If the object is COM then C# can directly interop with it. (This is why you can't add it as a reference directly)
However I think what you are really wanting to do will involve a P/Invoke (calling C/C++ native code from C#). This is entirely possible but it's not always easy. You need to deal with conversions between your C++ API and your C#, pointers and you need to be very careful to pin any references that your C++ code writes to in the C# app.
C# code is managed code (runs in the CLR), and can only directly* reference managed assemblies. So of course you're getting an error when you build against a managed assembly, and then sneak in and replace that managed DLL with an (incompatible) unmanaged DLL. You're basically trying to lie to the compiler, and that generally doesn't end well.
If you want your C++ DLL to be accessible from C#, the simplest way to do it is to build it as a managed assembly (i.e., CLR support). Which you're already doing. Just take out the extra step where you replace the working managed DLL with a non-working unmanaged one.
Also:
C++ dll with some additional functions (unmanaged code) to access the required functionality of my engine from the C# editor
That won't help you, because C# can't directly* call unmanaged code. The simplest way to make this work will be to make additional managed classes and methods in your C++ DLL. Then your C# assembly will be able to directly use those managed classes.
* As Spence noted, you can use -indirect- means (P/Invoke and COM) to access unmanaged code from C#. But that will make your life much more complicated than it is now, not to mention how it will complicate your build and deployment. You're already really close to something that should work -- don't add all that extra complexity.
When calling functions with P/Invoke, you don't add the DLL to the C# project resources (or what you probably meant, references, either).
You will add it to the file list in your MSI project, of course.