Develop Reference

VBA runtime error 453 with declare statement [duplicate]

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

Should I use Managed C++ or C# for my application?

If you had to decide between C# and Managed C++, which would you choose and why?
Are there benefits of Managed C++ over C#? Which language do you prefer? What decisions would you make under what circumstances?

I would use managed C++ if I:
Needed to integrate with existing C/C++ code
Needed to port existing C/C++ code to .net
Needed to use .NET objects from C++
Needed to expose .NET object over COM in a more complex way than what .net makes easy
Needed to access hardware directly
Needed to call lots of unmanaged APIs
And already had some skills in C++, as the above tasks will need a experienced C++ programmer. Most of the time I would only consider managed C++ if the company already had a C++ code base, otherwise who is going to maintain the managed C++ code.
In other cases I would always choose C#. Even if I choose managed C++ for part of the system, I would try to write as much of the system as possible in C#.
Think of manage C++ as a bridge building kit for going between the
unmanaged world of C/C++ and the
managed world of .NET.
If you only need to call a few simple APIs from C#, then see pinvoke.net and this overview to find how to call them from C#, as a few lines of complex pinvoke code (prebuilt bridge) in C# is normally better then introducing C++ to a project that is not already using it.

what is the benefit of managed C++
over C#?
C++.net is useful for interacting with C++ and C code (that is, calling external C or C++ libraries, providing callback functions to external modules written in C or C++ and so on.
what language of both would you
prefer?
I would prefer C# for all situations except the one described above (interacting with C and C++).
C# is easier to write, simpler, and geared specifically to use the .NET platform. C++ can do it also, but it has all the complexity of the C++ language plus the extensions needed to use the .NET platform.
Unless you need to interact with native C++ or C code, you're better off using C# in most cases (that is, if you're coding for the .NET platform).
Normally I prefer C++, but when needing to code for .NET, it doesn't beat C#.

Managed C++ is good for interop with C++: for example, if you have a .NET application and your assembly has to interact with a native interface that comes as C++ .lib files (which I had more than once), or with a nice C++ API.
Example: Rithmic (not that you ever heard of them) until recently ONLY supported a C++ API. If you try to access them from C# - good luck ;) Managed C++ allows me to access their API and expose nice .NET objects.
Basically interop. Managed C++ REALLY shines in interop with low level C / C++ API's.

I used managed C++ when I needed to build up new NET component with much ofC++ unmanaged code inside.
I did a specific class used to Marshall some objects forward and back from old C++ code.

I've encountered a problem which was transparent in managed C++, but made a big headache in C# - I had to send a callback function to a C++ unmanaged library, that defined this callback as __cdecl. In C#, the default calling convention is __stdcall, and it is pretty compilcated to move a C# delegate from __stdcall to __cdecl (Actually it requires either a 'shim' unmanaged DLL to do so or using some reflection classes).
In C++, (C++.Net as well), it is just a simple attribute.

I haven't personally written, or read for that matter, too many lines of code in managed C++, but from what I have seen it looks too convoluted and patchy. That said, you might want to use managed C++ if you are really good in C++, and when learning the idioms and patterns of a new language would be too much of a risk.
Use C# if you are quite competent in it. If you are only getting started with C++ and C#, I think, C# is the easier route to take.

I would prefer C#, or specifically .NET, over C++ because of the extensive .NET standard library.

Using DirectX DLL (C++) from C#

I have a native C++ DLL using DirectX, that I want to be able to use through C# to be able to create content creation tools.
Adding COM would require quite an effort it seems.
Can P/Invoke be used to maintain classes using polymorphism, or would it require me to wrap most of the code to facilitate use of P/Invoke?
It there a better solution is available? Or should I even consider writing the tools in C++ using Qt perhaps?

I always feel that C++/CLI is always the best option when doing C# to C++ interop. You can easily create thin wrappers for an unmanaged library that will look exactly like a managed library to your C# code. It also gives you more control over how marshaling and pinning is performed.
There are ways to automatically generate C++/CLI I believe, but I've never used them.
More info on C++/CLI here:
http://msdn.microsoft.com/en-us/magazine/cc163681.aspx

I presume rendering with D3D directly from C# isn't an option? (because that certainly would be easier!)
A long time ago, I used SWIG to automatically maintain C# "bindings" of my C++ rendering DLL code. It uses P/Invoke to expose the C++ objects on the C# side, and you won't have to maintain that code anymore.

You don't need to write wrap on QT.
I advice you to write Observer class both in C# & C++, and hide calls of Native functions to it.
Schema is like this
Your code in C# -> Observer(C#) -> Native call to Observer(C++) -> Calls to your dll.

Creating C++ Dll, and call it from C#

In my project I got a device which comes with C++ Sample codes. The codes are ok and the device is working as expected.
But I need it to talk with my C# interface because all other devices are currently using C# interface.
So I am planning to create a DLL Wrapper for the driver. I will create a C++ Library of my own (from source code with proper interface) and Call this C++ Library from C# using DLLImport (just call my interfaces there.).
I am pretty sure it can be done this way, but I have never created a C++ Library and used it from C# yet. So, can anyone refer me to some tutorial that goes with my problem?
I am using C++/C# int VS.NET 2008.
Regards,
Maksud

Have a look at
using a class defined in a c++ dll in c# code

Another useful tool you have at your disposal is C++ CLI.
You can use C++ CLI to create an intermediate library - one that exposes managed classes but runs unmanaged C++ code. You can actually mix managed and unmanaged C++ in the same DLL.
The unmanaged portion can accesses the unmanaged DLLs without having to use the PInvoke functions.
Your C# code can access the managed classes in this intermediate library.

Depending on the DLL and what you need to do you may not need to create a wrapper directly. You might be able to get away with P/Invoke for the functions. You will need to evaluate your specific needs and what is already available in the libraries/code provided.

For anyone who comes to this question and are looking for answers, you may want to try xInterop NGen++ , a C# wrapper generator for native C++ DLL, which has been just released to the public, the tool can generate C# wrapper for native C++ DLL automatically and instantly by using advanced P/Invoke technologies. Check out the current version and a free version will be out soon.
(I am the author of the tool)

Call C# methods from C++ without using COM

Is there a way to create C# objects and call methods from unmanaged C++, but without using COM Iterop? I am looking for something like JNI (but for .Net), where you can manually create the VM, create objects, etc.

If you are using C++/CLI then you can interact directly with both the managed world and unmanaged code, so interop is trivial.
You can also host the CLR yourself, and whilst the hosting API is COM based, you can then create any managed object. The process isn't a difficult as it sounds as a few API calls encapsulate a lot of functionality. There is a lot of info online, for example the MSDN documentation on "Hosting the Common Language Runtime".

There is a somewhat "undocumented" way of exporting C style API from a .NET class / method.
This ultimately leads to a situation where a .NET dll has exported APIs that can be called from C/C++ or anything that can consume .DLLs for that matter.
If you are into "reading" (beh ;) you can get a book called: Inside Microsoft® .NET IL Assembler where you'll find this technique in chapter 15: "Managed Methods as Unmanaged Exports"
There's also a nice example project on code-project you can use as a starting point for 32-bit environments:
http://www.codeproject.com/KB/dotnet/DllExport.aspx

You can decide file-by-file in your C++ project whether or not to use managed C++. Try changing the settings a file in your project so that it compiles as managed. Put the calls there to your C# object.
There's a cost to crossing the C++/C# border, so you should analyse where to do it. Like, you wouldn't want to do it inside a loop.

I am author of jni4net, open source intraprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.