We Keep Coding

How to use a C++ project from within a .NET application?

I'm a regular .NET developer aiming to integrate a C++ library into a .NET project. I have a few ideas, but since I'm new to C++ in general I don't know the limits of the technology I'm trying to work with. The C++ project is essentially a fast sound renderer that can playback multi-track audio files with a bunch of different postprocessing tricks. All of this is cool, but considering I have a simple .NET WinForms app I want to integrate with, things start to look messy.
Firstly, the C++ project has no .NET bindings or ActiveX/COM integration. Its a plain 'ol MS VC++ 9 project. If I am to work with the project in my .NET app I'll have to somehow interface with it, ie. create class instances, set properties, call methods, marshal data in and out, etc.
Secondly, its built to run as an independent Windows app and manages its own windows using the MS Windows API. This is fine, but somehow I need the .NET VM running in the background, managing the show and running all my C# code. I don't write C++ so I need to stick with C# to build an app around this lib.
Thirdly, whether I'm running in the same process as the C++ lib or not, I need a way to build/interface/debug these 2 separate apps as if they were one. I have no background in C++ programming except for the fact that I have written a couple C++ DLLs for high-performance data manipulation.
So, many questions and no idea how to start!
I can fully compile this lib and get it into a VC EXE, but how do I co-compile my .NET code into it? Or alternatively, how do I compile the C++ code into the .NET EXE so it runs within a managed environment? Note that it wasn't designed for this and may misbehave if I attempt to change too much.
The main problem is interfacing with it. How do I expose some C++ classes to be accessed from .NET? I know exactly which classes I need and I'll need only a couple dozen classes along with their relevant methods/properties to be available from .NET. I don't mind handwriting wrapper classes in .NET to help the .NET VM understand the class structure of the bytes transferred back and forth. I'm hoping I can directly work with C++ objects from a managed environment so most of my code can remain in .NET.
Even if I run it as an independant app, would I have to resort to sockets or something to communicate with it? This is the absolute worse case and I'll do anything to avoid this.
Any help or pointers are appreciated, I hope I made myself and my task at hand clear and that my questions are specific enough and answerable. Thanks for any help!
Edit: If I write wrapper classes or generate them, can I use P/Invoke to create class instances and call methods on them and have them run native C++ code in the background? Where will the memory for such C++ objects be stored and managed? Within the .NET heap or outside it?

You can write managed C++ (C++/CLI) wrapper to unmanaged C++ code. It would be the most flexible solution. Basically, you write a .NET assembly in C++, the assembly exposes managed classes which call your unmanaged code. Then you can reference this assembly from your C# projects.
There is a very basic article how to do that: http://www.windowsdevcenter.com/pub/a/dotnet/2004/03/29/mcpp_part3.html
This might be helpful as well:
http://www.multicoreconsulting.co.uk/blog/c-snippets/how-to-call-unmanaged-cplusplus-from-csharp/
And MSDN article .NET Programming in Visual C++.

Option 1
If you intend to use unmanaged C++ objects, it is probably better to write a managed wrapper in C++/CLI that has the same interface as the class that it's wrapping, but has a managed constructor and destructor to clean up the unmanaged resources. In C++/CLI you create unmanaged objects just like C++ that you have to delete yourself, or you can create managed objects with the gcnew keyword. The .NET facing side of the wrapper would take managed objects. The Native facing side of the wrapper could operate on all of the unmanaged data types that you already have.
For example, consider the unmanaged class Frobber. In C++/CLI, you would create a class called ManagedFrobber that would have all of the same methods as Frobber and contains a private instance of a Frobber. In the ManagedFrobber constructor, you would create your private Frobber instance. In the ManagedFrobber destructor, you would delete your private Frobber instance. Every method in your managed wrapper class would simply call methods on the private Frobber instance.
Option 2
If all you intend to call from the C++ world are c-style functions (static in the C# sense I guess), then P/Invoke is probably the way to go because then you don't have to worry about all of the nuances of a wrapper class. For example, if you pass an array from the Managed world into the Unmanaged world using a wrapper class, you have to worry about things like pinning the array in place so it doesn't get moved around by the .NET runtime while the managed world is messing around with it. With P/Invoke most of these nuances are handled for you.

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.

Port unmanaged C++ project to C#

I need to port a C/C++ unmanaged project (VS 2008) to C# (preferably .net 3.5).
Are there any conversion-helping
tools; let's say something
translating the code syntax and
asking you verifications/modifications for each
problematic point (I guess I'm dreaming...)
Where can I find some useful howtos or articles about this translation.
They would be very useful if they contained specific hints like:
extern variables should be set in public static classes
(I don't know, I'm guessing...)
Please no suggestion like "You can call your c++ dll from .net", because I know it's possible, but just I can't.
Note:
The C/C++ project uses only STL and
other basic functions, no 3rd Party
libraries etc.
I can't use it directly or wrapped
from C# because our company needs to
mantain/modify the code and we're extremely
more skilled in C# than in C++.

It will cost you far more to convert it than to wrap it and pay a freelancer (like me) to help you out by changing the C++ code for you every few months (or every few years) when you need to make a change. There are some mechanical approaches but the bigger issue is that you can never really be sure that the new C# code does exactly what the old C++ code did. I have clients who have tried this and most gave up and threw the work away. The ones who succeeded did it very slowly, like this:
First, you wrap the old library and get your UI or whatever the new code is (web service, whatever) successfully calling the old library. This gets everyone some "bang for the buck" and buys you time to solve the "we can't maintain our old code" problem. You also develop a comprehensive test suite that proves what the old library does for various edge cases and strange things that only happen in the wild every few years. Over time, you move functionality from the old library into a new C# one and change the calling code to use the new library for that functionality. You move the most volatile parts, the things you change most often, out first. At every stage you run the test cases again to make sure your translation from C++ to C# didn't mess up the results it calculates. Maybe some of it you never move out, maybe in the end it is all moved. You stop when you feel the risk of being unable to maintain your own library and needing to pay someone to do it for you has dropped below the cost of continuing to translate it.
I recommend you have access to someone with good C++ skills when you start. You will probably run into things that don't make much sense to you. But you can get the value from the library pretty quickly, and still solve your underlying problem in the long term.

Depends on what you mean by port.
You can rewrite some of the stuff in C#. Not everything. Some HW or legacy libraries would have to be handled with C/C++ even if you port your own code. I don't know of any reliable automatic converter for C++->C#, and I doubt one can exist.
A better idea may be to wrap your existing code in new C# code. You could create an interop layer in C++/CLI, for example. Or you can communicate with your native code with something like Google Protocol Buffers, if you don't want to mix native/managed code in the same process.

I doubt code conversion tools would help. If you need to make some C++ work in some fashion with .NET, the easiest way is to write a managed C++ layer that wraps it and provides an interface for .NET apps to work with. But it depends on the code.
What is the purpose of rewriting and what does your code do? Does it interface with other components? Does it have a GUI? Is it a standalone executable or a library? Is it a COM / ActiveX server or does it use COM components? Does it link to other DLLs or use 3rd party libraries?
All these affect how you're going to port / rewrite from scratch your app. For example, if your code is an MFC app you may as well forget trying to salvage much code. If your app does http / high level networking stuff you may as well write from scratch. If your code low level you might have to refactor with some C# and some C++ accessible through a managed C++ layer.
Lots of choices and it really depends what your app is doing, how it was written etc.

Why should C# developer learn IronPython?

We all knows that C# is a static language while Python is a dynamic language. But I want to know what are the features that Python has and c# does not. Also, is it advisable/beneficial to use IronPython with c# in the same application?
Also what points I should focus to learn before I try to convince my boss to use IronPython?

In other words, what points I can give to my boss to convince him to use IronPython?
Don't. If you don't know why you should use a new tool and for what, don't try to convice anybody to use it. At work, you should try to solve problems with the best tools for the task, not throw the fanciest tools avaiable at your problems just because they're fancy.
Learn IronPython, maybe make a small side project in it, find out what the strenghts are. Then if you think these strengths are useful for the project you're working on (e.g. for "glue code", plugins, macros etc.), convice your boss to use them.

One of IronPython's key advantages is in its function as an extensibility layer to application frameworks written in a .NET language. It is relatively simple to integrate an IronPython interpreter into an existing .NET application framework. Once in place, downstream developers can use scripts written in IronPython that interact with .NET objects in the framework, thereby extending the functionality in the framework's interface, without having to change any of the framework's code base.
IronPython makes extensive use of reflection. When passed in a reference to a .NET object, it will automatically import the types and methods available to that object. This results in a highly intuitive experience when working with .NET objects from within an IronPython script.
Source - Wikipedia

Need to 'wrap up' a C++ dll/h/lib/xml/exe based SDK into a COM to use in a C# 2.0 project

I just got handed an SDK made of C++ dll, lib, exe, and various .h files. I presume it is meant for C++ developers. The sample projects they provide with their documentation are all written in C++. I am able to spin them up with Visual Studio 8 (2005) and run them. They do control the device as advertised. However the project this needs to be used by is in C# .Net 2.0 and that is unchangeable.
My boss was a C++ developer and says all I need to do is to compile it as a COM object and then import the COM object into my C# solution. My boss says it should take less than an hour to "wrap" there SDK up as a COM object, even for me with no knowledge of C++ compiling.
I've used COM objects in C# solutions before so once this is made, I can continue on from there without a problem.
However, I don't know what to do to make the COM object from the 2 .dll files, 1 .exe, 1 .lib file, 1 .xml file, and the 12 .h files. Is there a resource available to tell me what to do to make this happen?

My boss was a C++ developer and says all I need to do is to compile it as a COM object and then import the COM object into my C# solution.
That's true, however compiling it as a COM object is "difficult" (by which, I mean that you can't do it) unless it already implements the COM APIs (if it doesn't then you need to implement the COM APIs before you can build it as a COM object).
There are books (for example, Essential COM) which explain how to to create COM objects using C++, but it's non-trivial (for building COM objects there may be better books than Essential COM, and better/easier tools than C++).
I think you and/or your boss have 3 options:
Ask the vendor to give them to you as COM objects
Design a COM API that would wrap the SDK's API. Create a COM project (in the language of your choice) which exports this API. Implement these APIs by invoking the underlying SDK methods. To do this you may need someone who knows C++, or be willing to spend much, much longer than "an hour" on this project.
Forget about using COM; instead, build the SDK as a DLL, and use PInvoke to invoke it from .NET code.
My boss says it should take less than an hour to "wrap" there SDK up as a COM object, even for me with no knowledge of C++ compiling.
Based on what you've said I don't know of any way to make that happen.

Tell your boss if it would take him less than an hour to wrap it up, he should certainly do it: it would be a more efficient use of both your time.
I would also suggest ATL (not using attributes), but this is something which can take some time to get right if you're not experienced.

My boss says it should take less than
an hour to "wrap" there SDK up as a
COM object, even for me with no
knowledge of C++ compiling.
That may be true for an experienced C++/COM developer, but not for a beginner. I think your best bet is to use ATL. Take a look at the MSDN tutorial.
And do not use attributes.

This doesn't quite answer your question, but...
One option instead of trying to make a COM object is to use P/Invoke and just call the methods in the DLL.
This thread on the MSDN Forums documents how to make a DLL to call using P/Invoke.
Of course if you need access to a whole class (and make an instance of said object), this isn't going to be helpful.

It's good that the code compiles and runs for you. That said it's totally unfair to assume you can do this in an hour.
Have you checked to see what is actually being built by Visual Studio. There could be a chance that it is already building a COM object.
Investigate how the code is being called. I assume you have a .exe that you can run to test the code. Step through this in the VC++ debugger (it's similar enough to debugging C# code) and try to identify any API calls that match with your docs/expectations. This knowledge will be helpful if you try to go the P/Invoke route.
Something else to consider is SWIG. This is typically used by Python developers to wrap C/C++ code and provides some support for C#.
The managed C++ route is probably more advisable for experienced C++ devs because you need to understand a lot about memory allocation, for all but the simplest code.

I (well, really my lead and I) will first try using p/Invoke (via the DllImport feature of System.Runtime.InteropServices) against the SDK's dll the company provided. I'll let you know how it goes.

I think what you really want/need is C++/CLI, that way you can just build them directly into a managed assembly. The idea is that you write a pretty plain wrapper that looks like kind of a cross between C# and C++ and then it does the rest.