C# GUI Frontend

Is is possible to make a GUI in C# but make the actually program in C or C++.

Like say I want to make a chat application. I want the interface to be in C#. But I want to make all the actual code in C. Is this possible?

I found http://www.google.com/search?hl=en&q=P%2FInvoke&btnG=Google+Search&aq=f&oq=

does anyone have any better kind of information?

From stackoverflow

• Absoluely! A c# winform can call into managed or unmaged C or C++ dll's. See P/Invoke for more information.

  Edit: Turns out there's a good thread on P/Invoke on the front page. :)

  Lucas McCoy : +1 for linking to an answer on my question.

  Lucas McCoy : ...oh and some good information also!

• Incrementing on JP's totally correct previous answer, you can also expose your C++ code through COM interfaces and then consume them in C# via COM/Interop. Good luck, though.

• Everything you can do in C can be done in managed code. Why do you want to build one component in C# and the other one in C? Are you worried about sockets?

  But to your question, you can absolutely do it as JP mentioned above.

  Cyril Gupta : I agree, unless it is prohibitive it makes poor sense having half your program in C# and half in C.

  Bob The Janitor : That's like telling a carpenter he only needs one type of hammer, use the best tool for the job, a framing hammer for framing, and a sledge for driving Spikes. Same thing for Programing, use the language/framework that fits the best.

  Mahatma : IMHO, your statement "Everything you can do in C can be done in managed code" does not hold good every time.

  CodeToGlory : @Bob you are wrong Bob, you are comparing an entire set of languages+Framework to a Hammer, instead it is the whole toolset. You can use a toolset from craftsment or a toolset from another company to fit all your needs.

• Not only is it possible, it might very well be what you should do. There's no reason to rewrite all of your existing code for .NET.

  In short, there are three ways to use existing (C/C++) code from C#: for easy access to a few simple APIs, P/Invoke works well. C++/CLI will give you the most flexibility. You third option is to use COM.

• Depending on how you want to distribute your application, you should consider the deployment requirements. If you have C++ modules, you will have a dependency on the C++ runtime libraries, in addition to the .Net framework. This is a non-issue if you are merely P/Invoking the Win32 API. This may or may not matter to you, but it mattered to me - I got rid of the C++ layer in my app, and resorted to calling Win32 directly.

• You already have some answers here giving you the affirmative.

  One suggestion tho: Premature optimization is the root of all evil (or something like that).

  Unless you are creating a science project (doing something just to see if it can be done), just write the entire thing in C#. Once complete, if you find you have parts of the project that are not performing well enough, rewrite those parts.

  Basically, the part of the application that are slow are rarely where you thing they will be.

  Bob The Janitor : @Chris your Blog entry asking people to tell you when your Wrong. In this case I think your wrong. There could be any number of reasons to not to write the whole thing in .NET. For example what if he is more comfortable working in c++, but wants the flexibility of WPF, or has an existing lib, etc.

  Chris Brandsma : I can go with that. It isn't a bad thing to write with where you are most comfortable (that is what we do most of the time after all). And sometimes you need to stretch (which could mean C++ or C#). The main goal is "better each time".