Windows Phone 7 has put the .NET Language Coevolution Promise in Doubt

I've always considered C++/CLI as a language specifically designed for the CLR, suited in particular to writing interop code, or to be used together with standard C++ code, e.g. to make legacy/portable C++ code accessible via web services etc.

I wonder if anybody has ever tried porting a real C++ codebase to C++/CLI, with all its extra syntax and differing semantics (arrays, ref/value types etc, references vs. pointers etc.)

Any experiences anybody?

I've used C++/CLI quite a bit in the last two years as an interop language where large chunks of the existing c++ code have just been dragged in and compiled. It works very well at that, much as Apple's hybrid of Objective-C and C++ allows you to mix the two languages.
You don't need to change the original C++ logic much or change your classes over to the new ref classes unless you're dealing with .Net interfaces and it's easy to have loops copy std strings and vectors to .Net types.

However, with WPF, the dependence on partial class generation needs a little work as WPF relies on being able to generate half a class declaration in a background file (for the controls and other members from XAML) and the rest in the "code behind file". There's a simple, if slightly ugly, C++ idiom that could fix this - just generate a large macro to be included in the code behind file's class declaration, that would expand to provide all the required definitions.

As I've written a code generator that goes from annotated XAML to generate pure XAML, C# and C++/CLI I know for certain this is feasible.

I guess I was not specific enough. Did you use /clr:safe to compile? Because otherwise, you're probably just creating unmanaged code via the normal C++ compiler backend. That won't run in Silverlight, WP7, Mono etc.
Unfortunately, if you turn it on, existing C++ code will most likely not compile. What I'd like to know is if anybody has ever tried to port a significant amount of code so that it would compile with /clr:safe.

No, just /clr because I'm creating mixed code. Some of my classes are pure C++/CLI, like a large XML reporting engine that is generating report files used externally by an XSL:FOP chain and internally with a WPF preview window directly binding to the XML (in C#). This is a good example of where I think C++/CLI fits as a language - being able to choose how much stays native and how much is new. I find using the ref-style classes very easy, only being a minor variation on style. That might be because I've used smart pointer idioms for over fifteen years so I'm used to not having many explicit deletes.

Frankly, unless you have problems with memory management, I don't see why you would port a large code base and rewrite it with ref classes.

I researched the Silverlight issue about 18 months ago and it wasn't confidence inspiring, for example forums.silverlight.net/forums/p/5329/16357.aspx says
Even if you take the utmost care to compile your C++ DLL with pure CLR, and you replace the normal references with Silverlight ones, Silverlight still gets upset when it tries to open the DLL because it contains references to MSVCRT90.dll, KERNEL32.dll, and MSVCR90.dll.

and

I just gave Silverlight&C++ it a try by compiling the MSIL from my C++ project into a Silverlight-compatible DLL. The good news: it works, and you can call this code from a Silverlight project. The bad news: The C++ compiler apparently uses MSIL instructions that Silverlight disallows.

So, if you try this, even with the simplest of programs, you'll almost immediately get the exception "Operation could destabilize the runtime." To me, this makes it seem less likely that we'll see Silverlight for C++ soon, as the compiler will need to behave quite a bit differently.

I forgot to mention that Stefan has now of course clarified the other big reason for converting your native C++ to C++/CLI - wanting to run it under anything other than .Net on Windows. stackoverflow.com/questions/2455372/windows-pho... is a good thread.

The win7 move makes smart business sense. Put another way: How much do I pay as a C# developer who buys MS tools for keeping VB.net alive? Consider that question both in concrete dollars for the tools and in opportunity cost as MS is diverting resources away from other projects to maintain something for maybe 10% of its developer audience.

and I meant winphone7, not win7 ;)

the question is not "does c++/cli work with SL/WP7 today?"
sure, it is not supported, but it is easy to see that MS *could* support it - but only in the restricted /clr:safe mode. so the question remains:

does it make sense to port a large c++ codebase over to c++/cli?

or is the porting so much trouble that you might as well just rewrite it?

there's a lot of c++ that you can still do in /clr:safe mode, like templates or some pointer arithmetic.
but no MFC, no ATL, no 3rd party/OSS libs (Boost!) unless you port them too. STL is available, but only in a special version (freaky: combines generics & templates in a _very_ interesting way).

According to past Microsoft reports, the VB audience is actually larger than the C# one. I suspect that VB is more popular with non-professionals than those like us, but its hard to say because there are countless IT-department programmers cranking out internal applications that we'll never see.