I like C++/CLI. I think the ability to write native code along managed code is a great benefit. Especially when I have so many existing C++ native projects (MFC & ATL). However, this needs to be done somewhat carefully.
Microsoft says all you have to do to enable managed code in a C++ app is to click Project->Properties, change in the General section to allow managed code (/clr being the most useful option) and voial! IJT (It just works). Technically, that's mostly true (mostly, because in one instance some unknown code called ::CoInitializeEx(0, COINIT_MULTITHREADED) before my MFC InitInstance method executed, causing the main thread to enter the multithreaded COM apartment. Then MFC's AfxOleInit which calls ::OleInitialize - tried to enter the STA failed of course as the apartment of the thread cannot changed once established. Calling CoUninitialize is no solution either, as it will throw away all COM objects in the current apartment. Also, if you have inline assembly or varargs stuff IJT will fail too. Nevermind...)
If you try this on a medium-big MFC project, for instance, you'll find out that the "Linking" phase takes a minute or two on a capable machine. Wondering why, you take a peek at the output file and note that it has grown from something like 4MB to more than 150MB! All that metadata of all unmanaged types wrapped up in managed code!
The solution to this is somewhat more difficult, but well worth the trouble. Don't enable the /clr option globally. Rather, enable it on per file basis in which you need to call managed code. You'll have to get rid of the precompiled header too, but that's a small price to pay. Then, to be extra compact, you can wrap the managed functions/types in #pragma managed/unmanaged to better control the compilation mode. This way you get all the benefits without (almost) all the baddies.
I do like C++/CLI!