We Keep Coding

Automatically perform C# wrapping of a C++ library

I've done a bit of research around this before posting but I couldn't find a direct answer specific to my environment.
I have a third party library written in C++. I have access to the .dll, .lib and .h headers of the library.
I'd like to wrap the library for use in C# using p/invoke. I'd like to know what options I have in terms of doing this and maintaining it. My hope here is that with the .h headers I can utilize some application to automatically provide the wrapper code.
I'm interested in all kinds of solutions including commercial software solutions and any pitfalls of trying to automatically manage the wrapper code.

You could try SWIG which is free. You may be able to script it to run automatically as part of a build process.
Personally I'd just write some wrappers using [DllImport]. Do you really need to access everything in the C++ library from C#? Often I've found you really only need to call a few functions, and the simplicity of dllimport is great

My hope here is that with the .h headers I can utilize some application to automatically provide the wrapper code.
It would be lovely if this were possible, but it is not. It is not possible because the header file does not contain enough information to determine how to marshal parameters. For instance, consider this declaration:
void foo(int *x);
What is x? Its type is int*, pointer to int. But is it a pointer to a single int value, or is it an array of int? You simply cannot tell from the header file. You need to read the documentation.
And what about data flow. Is the information flowing into the native code, or out of it, or in both directions? Again, that detail cannot be expressed a header file.
Now, there are various annotation conventions that can help with this. Essentially these are macros that evaluate to nothing that can be read by a tool and so help with conversion. You see Win32 API functions annotated with _In_, _In_Opt_, etc. These can help, but only the very simplest of libraries can be automatically translated into p/invoke declarations.
Now, if you are prepared to add extra annotation to the raw header files then you might have a chance. It is certainly possible that existing tools exist that will do a good job so long as you express the missing information in comments or macros. SWIG is certainly worth a look, and there are other tools.
The fundamental point of my answer is to try to get across the idea that such translations are not as automatic as you might hope. Personally, I always end up writing my p/invoke declarations by hand. This allows me to get them exactly the way I want, and maintenance is not really a big deal because DLL interfaces typically don't change. They don't change because you don't want to break binary compatibility.

What is the best way to port a C++ library to C#?

I have a (header only) C++ library that I am looking to port to C#. It is a wrapper of the win api which I have made for a certain purpose. I want to port it to C# because I want to develop it further using C#. What is the most efficient (and easiest?) way to port it. Please note that I do not want something hectic because I don't want to spend more time porting the library than it took to make that library in the first place. So is there a way?

It depends very much on how big your lib is, how it is structured, how your memory allocation looks like, how much you made use of libs not available in C# (like the C++ std lib), how much C++ template programming you have used etc.
Different strategies may be
try to port (parts of) it automatically by some code generator of your own
do not port it to C#, instead use C++/CLI (something I did very successfully in the past)
do it manually because the C++ concepts you have used so far don't map well to C#
"Header only" does not seem to make a real difference. In fact, things may technically get a little bit easier when you have just one C++ file for each class to be ported to one C# class file.

A couple of ways I can think of.
Manual conversion to C# dll with possible code generation help of T4.
Change your c++ library to a managed dll so you can use it in your c# project.
Of course, you might use interop with your c++ library in your C# project. But in that case, I am not sure about purpose of your c++ library since you said it's a wrapper.
Since you already have c++ library that you can fully control, I would try to go with #2 first.

Is C++ and .NET used together in Domains like Banking , Health Care and Telecom

Or I should ask how helpful and benifitial will it be to start with C++
This may seem irelevant but it has some significance for me,may be few others like me.
I just want to know ,How Important is it to Learn C++ , COM and ATL while you are a .NET programmer?
I love programming with .NET and C# .Visual Studio just has it's own charm of intellisence ,Color Coding and other pretty features , which make us addicted to it.
I was thinking , almost we can build anything with C# and still it holds true mostly, but it lags sometimes like:
While I try to create a Shell Extension , then it is highly suggested to use unmanaged code instead of any managed code.
Also there are few other things like COM , ATL , which are preferred to be coded in C++ rather than C#.
I am just 4 years in IT industry and love to be Solution Architect.
So need all your inputs to know , how important/helpful will it be in my future venture if I am doing my Current COM Project with C++ , which integrate with .NET UI.
Is there any implementation of C++ and .NET in common domains like Health Care, Banking and Telecommunication.

The issue (at least for the specific cases you mention, such as shell extensions) with trying to "integrate with a .NET UI" is that you really can't. The reason it's not a good idea to write shell extensions in managed code is that a given process can only load one version of the CLR at any given time. If two shell extensions depend on different versions of the CLR, and they both try to load at the same time, it will fail. You can't load the CLR in any way shape or form in the context of your shell extension and be a well behaved shell extension.
My advice would be to not bother with C++ until you really have a reason to learn it (despite that C++ is my favorite language). But when you do learn C++, leave your .NET baggage at the door. There are lots of things (such as excessive use of casting, constantly using new, etc) which are idiomatic C#, and are just plain wrong in C++. You will be a lot happier if you don't try to understand C++ concepts in terms of the CLR -- simply because C++ doesn't run there. You can use some of the design patterns you may have learned for C#, but how the underlying language and machine operates are completely different between the two languages.
Probably the most confusing difference for new C or C++ programmers is the concept of undefined behavior. The C and C++ standards are written in such a mannar as to not be tied to a particular machine. This is in stark contrast to architectures like Java or .NET, where the language is actually defined in terms of a virtual machine (and therefore is extremely dependent on that VM). This leads to places where the standard literally does not say what the correct output of a program should be; and instead says "however the underlying machine usually does this". You'll probably notice this quite a bit if you're ever dealing with floating point math. While C# has strict and specific rules about how and where floating points are calculated and rounded, C and C++ make no such qualifications.
Once you understand C++, then you can move on to COM and ATL. COM is essentially designed to make a C++ like class structure accessible in a language (the COM ABI), machine (marshalling between 32 bit and 64 processes on the same system, etc), and location (DCOM provides RPC facilities) independent way. If you don't understand the C++ object model, then you're going to have an extremely difficult time with the COM object model, because the two are extremely similar. ATL is a set of C++ class templates around COM fundamentals which simply handle some of the boilerplate for you.

I just want to know ,How Important is
it to Learn C++ , COM and ATL while
you are a .NET programmer?
Depends what you do. You are way better of learnin about databases. Pretty much every serious app uses a database.
But C++ IS ued together with .NET - especially C++/CLI (the managed variant) as it is very good for integrating C++ code with managed code effficiently. Quite often pretty much the only efficient way. Which is important if you for example raise events for market data. With a frequency in excess of 100.000 times. Per second.
But this is a NICHE. I work in the financial area, and tthe C++ uses AND integration uses are SMALL compared to the people working in .NET / In the application.

C++/CLI: why should I use it?

I'm pretty familiar with C++, so I considered learning .NET and all its derivatives (especially C#).
Along the way I bumped into C++/CLI, and I want to know if there is any specific use for that language? Is it just suppose to be a intermediate language for transforming from native C++ to C#?
Another question that popped to my head is why are there still so many programming languages in .NET framework? (VB, C++/CLI, C#...)

Yes, C++/CLI has a very specific target usage, the language (and its compiler, most of all) makes it very easy to write code that needs to interop with unmanaged code. It has built-in support for marshaling between managed and unmanaged types. It used to be called IJW (It Just Works), nowadays called C++ Interop. Other languages need to use the P/Invoke marshaller which can be inefficient and has limited capabilities compared to what C++/CLI can do.
If you need to interop with native C++, classes that have instance functions and need the new and delete keywords to create/destroy an instance of the class then you have no choice but use C++/CLI. Pinvoke cannot do that, only the C++ compiler knows how much memory to allocate and how to correctly thunk the this pointer for an instance function.
The .NET framework contains code that was written in C++/CLI, notably in System.Data and WPF's PresentationCore. If you don't have unmanaged interop needs or don't have to work with a legacy code base then there are few reasons to select C++/CLI. C# or VB.NET are the better choices. C++/CLI's feature set got frozen around 2005, it has no support for more recent additions like lambdas or Linq syntax. Nor does the IDE support many of the bells and whistles available in the C# and VB.NET IDEs. Notable is that VS2010 will initially ship without IntelliSense support for C++/CLI. A bit of a kiss-of-death there.
UPDATE: revived in VS2012, IntelliSense support is back. Not in the least thanks to C++/CX, a language extension that simplifies writing WinRT apps in C++. Its syntax is very similar to C++/CLI. The Windows Forms project templates were removed, the designer however still works. The new debugging engine in VS2012 doesn't support C++/CLI, you have to turn on the "Managed Compatibility Mode" option in Tools + Options, Debugging, General.

First C# is not a 'derivitive' of .NET. .NET is not a language, it is an application framework and class library based on the CLR, for which a number of languages exist.
That said, the most compelling reason to use .NET is that it is a well designed class library and a much easier way to develop for Windows than Win32 or MFC. However I personally decided that I'd rather learn a new language altogether than learn extensions to an old one, and because C# was designed from the ground up to work with .NET, I suggest that is the language of choice for .NET.
C++/CLI is useful is you want to use .NET with some legacy code, and I have used it for creating Windows Forms GUIs and gluing them to existing application code. Its other raison d'etre is that it is the only .NET language that supports mixed managed and native code in a single load module, so it is good for both performance and reuse of legacy code.
With respect to the number of languages, Microsoft want every Windows application to be based on .NET because it is better for the security and stability of their OS. The only way that will happen is by supporting multiple languages. Think of .NET as an application platform or OS API, and then the question makes less sense; there will be many languages for .NET for the same reason as there are many languages for any platform. Those reasons are many, including commercial advantage, application fit, politics, supporting existing developers, choice and no doubt more.

Microsoft has changed its stance on this a few times. It was originally intended as a full-fledged language, essentially something that they wanted all native developers to move to, abandoning native C++ as much as possible.
Then a few years ago, they realized that this simply wasn't what their customers wanted. Developers who are moving to .NET anyway generally jump to a language like C#, and the rest have reasons to keep their code in the native world, so they stay with C++.
So now, Microsoft intends for C++/CLI to be a "bridge" between native C++ code and managed code written in some .NET language. It's no longer a language they recommend you switching your entire codebase to.

It's indeed mainly intended as intermediate language to easily link .net code with native, unmanaged C++. Do yourself a favour, don't use it if you don't need to. C++/CLI syntax is a mess.
Regarding your second question ... I think today C# is the dominant language in .net, but not everyone likes its style and paradigms. .net's architecture makes adding new languages easy (see F#, which aims at functional programming).

I've used C++/CLI to create .NET API's for some unmanaged C++ libraries. Passing and marshalling of parameters takes some getting used to (depending on used types), but once you've got the hang of it, it's really a nice way to bridge the gap between the managed and unmanaged world.

I have not looked at C++/CLI but it harnesses the .NET world - think of it as a in-between C++ and C# where you have the best of both worlds. It could be useful in situations where you want to use C++ that can easily access .NET objects and it's core BCL. Have a look here at this article discussing the primers of C++/CLI. Unfortunately, I have not heard of a Managed C++ application as it has ruffled a lot of C++ friends on the syntax side of things and lost gathering of followers who went back to the unmanaged world of C++.
Hope this helps,
Best regards,
Tom.

for me, i have to use it when there is no other way to reuse c++ class

This post is old but the most important message in my oppinion is missing: You use it for being able to see and manipulate the source code of C++ frameworks you use in C#. Examples: You don't use compiled OpenCV binaries, instead you got the OpenCV sourcecode in your solution and can add simple some Extensions, or deep check how some behavior exists. Or in finanicial math you could QuantLib Sources, and so on. This is much better than having already compield libraries that act as black boxes in a lot of ways. C++/Cli in .NET solves this.

Just so you know. Unless you specify the code to be compiled as unmanaged, when compiling with CLR support it will be compiled as managed code.
While CLI C++ is nice. I find it a pain to code in. There is just something about it that makes me not want to program in it. It isn't even the "^". It is like using a broken .net. I spent 40 minutes coding something fully managed in it that took me 10 minutes in C#. I mean, sometimes I just give up and use C# because it frustrates me when coding in it. I mean if you are going to use .net you might as well use C#(over CLI C++).

C# --> Java code generator

I have a small (~2000 lines of code) class that I would like to use from both java & .NET. There are several approaches to do this - among them wrapping the class as a service, using some interop voodoo, or duplicating the code to both C# & java.
Do you know an out-of-the-box tool that accomplishes the latter - takes a simple C# class with no dependencies and converts it to an equivalent java class?

IKVM.NET does pretty good job in taking a jar file and compiling it to a managed .NET assembly.

If it is small (or in fact, even if it is large), I'm not sure of the wisdom of mechanical translation tools; I've simply never had much joy with them. However, one option would be to write the .NET code in J#.
But I stress - if it was me, I'd manually port it between the two manually and maintain them separately. Most of the time the differences aren't huge - signed bytes, the boxing differences, etc. Of course, anything with delegates will need changing - and captured variables work differently, etc etc.

There used to be a COM bridge and you can register C# assemblies for use in COM with regasm.exe or visual studio.

It's not really what you asked for, but I would just create a simple C# to Java translator.
The differences are not that huge and you seem to be the author of the source so you can avoid nasty constructs that are quite difficult to translate. That way your translator would be quite simple. I would go from C# to Java because C# is more expressive, and you can emulate almost all the C# functions in Java.
Actually cs2java seems to do just that.

This is list of tools I know. Sharpen or j2cstranslator looks like good options.