As for me, I don't code C++/CLI with Visual Studio, so I don't care (professionally). However, I care personally, since IntelliSense is a very useful and time-saving feature, and removing it for C++/CLI is very annoying.
Yes DLLImport is nice but their are times, big times, when it is a headache. For example working with DirectShow c++ code, i.e. capture filters written in c++, and wrap up all the nasty code with working with the video capture graph so that in your little c# program you can work with a high-level webcam capture entity as if it was written in c# itself.
Yes you could write a c++ dll that returns some data and exposes some control functions... but that means in c# you have to have a ton of interop wrapper definitions, and every time you change something in the c++, well now you gotta update the c#.
C++/CLI is the easier way to NOT have to do any of that. You can work with the c++ objects from the comforts of a CLI class... i.e. you can work with the pointers and safe pointers etc etc. You can specify how to cleanup and finalize objects in the c++/cli... so that means no calling of "Free()" functions in c#, or else memory leaks... just let the object go out of scope like a c# object.
And when you compile, simply add reference to the C++/CLI project and off you go. No pesky interop stuff to work with... CLI really a pleasure to work with (intellisense would help) :P
I use it to write standard windows dlls and still have the power of the .net framework.
More info - I write add-ins to a software package that can only pull in standard windows dlls. But, I am a straight C programmer. I am also a C# programmer. I never got into C++. But with C++/CLI I've got the best of both worlds. I can code standard windows dlls and I can create great GUI in C# and I can tie the two together and pass data back and forth using C++/CLI.
I am still having to use VC6, a twelve year old development package, that is what comes from working on a large legacy package that can not be easily updated. I am begining to feel that there could be future in COBOL :>)
Ouch. I've done such a port, and I can certainly understand a reluctance on the part of any organisation to commit to it. However, knowing what I do of the advantages of moving on from VC6 (compliant for loop scoping is only the start of it) I can honestly say the pain of porting to a more compliant (and secure) version of Visual C++ is likely to be worth it in most cases. As a bonus, once you get past the initial VC6 -> VS2xxx pain, upgrading to newer versions is far, far easier.
If it helps, we recently had a request to support VC5 in one of our tools!
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
a) Other Interop technologies such as COM Interop and PInvoke are better and easier to manage. Actually, you will end up using it anyway depending on the project.
b) In case other technologies cannot be avoided use C++/CLI as a small thunk layer. Do not write majority of .NET code in C++/CLI. In fact, purely managed classes in C++/CLI are not worth the trouble anyways as IDE support for C# is far better than that of C++/CLI.