I've read many comments about GUI programming, in both, C# and C++. And I noticed that Microsoft's .NET framework is powerful for GUI programming. So is it possible to use C++ and .NET framework?
I think it will be a great combination since C++ is powerful language, and .NET framework is preferred for GUI programming on Windows, as I've read. Is it possible to write the GUI in C# and the functionality in C++?
Yes, it's formerly known as Managed C++ and now C++/CLI. You have access to the entirety of the .NET Framework (GUI: WinForms, GDI+, etc.) as you would from the other three bundled managed languages, C#, F# and VB.NET.
Do not forget about the most flexible and simple option, a typical for Unix world but, for some reason, not that common in Windows: splitting GUI and logic into different processes, communicating via any reasonable form of RPC (e.g., even a pipe should work). Preferably with a simple, human-readable text protocol.
This way you can implement you GUI (or various GUIs) with any technologies you fancy, and build up logic components from whatever suits the need better - C++, scripts, whatever else.
I'm not aware of any reasonable advantages of a monolithic design approach from the Windows world.
I did this once a few years ago, back in the days of Managed C++. We had some business logic in an umanaged DLL that we wanted to incorporate into a wizard-style GUI written in C#. To do this, I created a Managed C++ assembly to sit between the managed GUI app and the unmanaged DLL and used System::Runtime::InteropServices::Marshal within that assembly to convert values from managed types (System::Int32) to unmanaged types (int) and vice versa.
While Managed C++ appears to be deprecated, the same principal might apply to C++/CLI.
Not really. There is a hybrid language C++/CLI, but it's only good for interoperation (Microsoft's official policy). Because of the way the .NET framework is designed, there are many language semantics which really don't fit running on the CLR, and C++ exhibits many of them.
The C++/CLI angle has been covered by plenty of answers so far, but another way of doing this is to use PInvoke. This allows C# programs to call functions contained in dlls that were written in C++. The advantage of PInvoke is that your dll is totally agnostic about the fact that it will be called from .Net. This means you can call dll's for which you have no source code, and even if you did, you wouldn't have to recompile the source code using the /clr option. This means you can use this dll with other C++ programs, as well as C# programs. There are some fantastic C/C++ libraries out there: PInvoke allows you to take advantage of these. Sometimes Win32 libraries provide functions that just aren't available in .Net: PInvoke allows you to use them.
One of the trickiest parts of using PInvoke is knowing how to convert the unmanaged signature to a managed signature. But there is a cheatsheet to help with that.
You can also work with a C# dill via COM (Component Object Model). For me COM was better then using Managed C++ since Visual Studio 2010 doesn't have intellisense for Managed C++. In my case we already have a large C++ application but wanted to try to move away from MFC to WinForms or WPF.
