Question concerning Win32 Console app vs. CLR Console app

Question

Hello,

I'm working on a C++ project that I don't intend to develop or deploy using .NET libraries or tools, which means it would make sense for me to create it using a Visual Studio Win32 Console application. However, I've heard that the debugging abilities when using a CLR application under Visual Studio are much more powerful. So I have a few questions:

1. Is it true that having a CLR app vs. a Win32 app adds capabilities to your development process even if you don't utilize any .NET libraries or other resources?

2. If so, would I still be able to develop/compile the project as a CLR project to take advantage of these even though I'd be developing a pure C++ project using STL, etc. and not taking advantage of any .NET functionality? Or would such a project require fundamental differences that would make it non-trivial to revert back, meaning I should stick with a Win32 console app?

Thank you for your help.

Answer 1

Bottom line answer, if you are never intending to use the CLR or any .Net objects in your application, just use a normal Win32 C++ library. Doing anything else will cause you pain down the road.

Now, to answer the original question about debugging, yes debugging with the CLR has certain advantages over debugging a normal C++ app. Starting with Visual Studio 2005, both C# and VB.Net began to focus on making the variable display in the locals / autos /watch window much more valuable. It was mainly done through the introduction of .Net attributes such as DebuggerDisplay, DebuggerTypeProxy and the visualizer framework.

If you don't use any .Net types though, you will get none of these benefits.

The C++ expression evaluator does not take advantage of any of these. It has it's own methods of customizing type display. But it's not as featureful (or potentially dangerous) as the attribute style because it doesn't allow for code to run in the debugee process.

That's not to say debugging C++ provides a poor experience. It is merely different and there are better displays for many STL container types.

Debugging a CLR app also has certain disadvantegs. For instance, debugging optimized code is near impossible at times because the JITer will hide local variables, parameters and often "this". Debugging a similarly constructed C++ app can also be frustrating but you can always grab the registers and dissamebly to see what's going on. Doing the same for a CLR app is difficult at best.

Answer 2

I think compiling native C++ code into CLR opens a whole can of worms. Unless you have large investment on existing C++ code and some necessity to run the code with managed types, this is something you want to avoid.

For example, C++/CLI is one way to bundle native C++ code right into a CLR assembly, but C++/ CLI adds non-standard syntax to C++ language, and using native C++ types mixed with managed types seems like a very tricky issue to say the least.

So, in conclusion, I would just keep it as a native app. If you have any plan of porting it to CLR and you've just started working on this project, I would seriously think of start writing in a CLR-native language like C#.