Develop Reference

How can I add a C# GUI to C++ code?

I wrote C++ code in which are included some libraries and defined some functions plus the main. I am trying to add a GUI to this code in C#.
This code sends data (double[]) to a server. What I would make is create a graphic user interface using C#, that lets me to start sending data, clicking a button.
How could I make this?
I've tried to run the file .exe of the c++ project solution, but that doesn't work.

You have a lot of ways to run C++ code from C#:
COM
This is the canonical, good-bear way to do things, but I have a feeling this will be daunting at your level. Basically, you will expose your C++ classes as COM objects from your C++ project (dealing with converting between COM datatypes like _bstr_t for strings, et al). Then add this COM object as a reference in your C# project. This imposes the least pain on your C# code.
I suspect the biggest hurdle here is that you will need to understand how COM works, which is going to be pretty daunting if you don't already have experience in it.
C-like DLL
This is probably much easier, if you don't need to call many functions. It's the same as how you call native winapi functions from C#. You export C-style functions from your C++ DLL, and import them in C#. Converting between datatypes is done via the marshalling system in C#. So in general this places the burden more on the C# code, less on the C++ code.
The catch here is that you can't export much C++ stuff. So for example you cannot export a function like:
void myFunction(std::string& s);
Because std::string is a template, and will cause havoc regarding memory management and will probably just lead to heap corruption.
Rewrite in C#
If all you're doing is sending some data over a socket, then just write it in C#. For many things, C# is way faster than C++ for development, so it's probably worth looking into how much effort this would be.

C# Wrapper for C++

I'm working on an app that I would really like to write in C#, but I need to use a library that is in C++. The vendor supplements their DLL with some C++ code to make the API more convenient, which it does, but it's still C++. I'd like to incorporate this extra C++ code into my app. It seems reasonable to create a DLL to wrap the vendor-supplied C++ code and the other calls into a module that I can use in C#.
My question is, does it make sense to wrap a DLL in another DLL? Are the potential problems I should watch out for?
Best,
John

Wrapping a wrapper for the sake of creating a better API (or, in your case, a .NET API) is OK. You might face some interop problems, as they can always pop up when moving from managed to unmanaged code.

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.

How to call c# code from Fortran dll

Currently I have abc.dll which is fortran dll. Now I want to call C# code from abc.dll. Is there any way to call the C# code from fortran dll ?
thanks
Sagar

Typically, if your program is written entirely in native code (as I believe the Fortran dll would be), you'll need to call a method that's been exported (dllexport) from another native code module. In this case, you'll want to create a Managed C++ dll that exposes a native interface and internally makes the call into the C# code.
Edit: If the hosting program is managed code, and you need to do a C#->Fortran (native)->C# calling sequence, then delegates as unmanaged function pointers can be used as linked in the comments above. However, if the executable is not managed code, you'll need to go the route I mentioned.

Compilers supporting recent Fortran language features (the 2003 standard) will support C-interoperation. You interface with other code through its C interface, using the ISO_C_BINDING module and the BIND construct. Most recent compilers have it, it's standard and you can find a lot of documentation (like this one) by Google'ing the keyword ISO_C_BINDING.

Mixing C# Code and umanaged C++ code on Windows with Visual Studio

I would like to call my unmanaged C++ libraries from my C# code. What are the potential pitfalls and precautions that need to be taken? Thank you for your time.

There are a couple routes you can go with this - one, you can update your unmanaged C++ libraries to have a managed C++ extensions wrapper around them and have C# utilize those classes directly. This is a bit time-consuming, but it provides a nice bridge to legacy unmanaged code. But be aware that managed C++ extensions are sometimes a bit hard to navigate themselves as the syntax is similar to unmanaged C++, but close enough that a very trained eye will be able to see the differences.
The other route to go is have your umnanaged C++ implement COM classes and have C# utilize it via an autogenerated interop assembly. This way is easier if you know your way around COM well enough.
Hope this helps.

This question is too broad. The only reasonable answer is P/Invoke, but that's kind of like saying that if you want to program for Windows you need to know the Win32 API.
Pretty much entire books have been written about P/Invoke (http://www.amazon.com/NET-COM-Complete-Interoperability-Guide/dp/067232170X), and of course entire websites have been made: http://www.pinvoke.net/.

You're describing P/Invoke. That means your C++ library will need to expose itself via a DLL interface, and the interface will need to be simple enough to describe to P/Invoke via the call attributes. When the managed code calls into the unmanaged world, the parameters have to be marshalled, so it seems there could be a slight performance hit, but you'd have to do some testing to see if the marshalling is significant or not.

The easiest way to start is to make sure that all the C++ functionality is exposed as 'C' style functions. Make sure to declare the function as _stdcall.
extern "C" __declspec(dllexport) int _stdcall Foo(int a)
Make sure you get the marshalling right, especially things like pointers & wchar_t *. If you get it wrong, it can be difficult to debug.
Debug it from either side, but not both. When debugging mixed native & managed, the debugger can get very slow. Debugging 1 side at a time saves lots of time.
Getting more specific would require a more specific question.

You can also call into unmanaged code via P/Invoke. This may be easier if your code doesn't currently use COM. I guess you would probably need to write some specific export points in your code using "C" bindings if you went this route.
Probably the biggest thing you have to watch out for in my experience is that the lack of deterministic garbage collection means that your destructors will not run when you might have thought they would previously. You need to keep this in mind and use IDisposable or some other method to make sure your managed code is cleaned up when you want it to be.

Of course there is always PInvoke out there too if you packaged your code as DLLs with external entrypoints. None of the options are pain free. They depend on either a) your skill at writing COM or Managed C wrappers b) chancing your arm at PInvoke.

I would take a look at swig, we use this to good effect on our project to expose our C++ API to other language platforms.
It's a well maintained project that effectively builds a thin wrapper around your C++ library that can allow languages such as C# to communicate directly with your native code - saving you the trouble of having to implement (and debug) glue code.

If you want a good PInvoke examples you can look at PInvoke.net. It has examples of how to call most of win api functions.
Also you can use tool from this article Clr Inside Out: PInvoke that will translate your .h file to c# wrappers.