C++/CLI and Compact Framework: additional clarity

Based on the comments to my last blog post, I think I need to provide a little more clarity and context to get the feedback I'm looking for.  Reader Vyacheslav touched on most of the points, so let me clarify by addressing the issues he raises...

First is the code reuse. There is a need to use .Net types from within "legacy" code.

Yes, code reuse is certainly the big need here.  However, what I want to understand is the specific scenarios around code reuse.  For example, existing C/C++ code can be reused today in .NET CF scenarios by p/invoking from C#.  I'd like to better understand why this solution doesn't work well for you.

If we look at how we accomplish C++ reuse on the PC-side of things, there are two additional flavors to consider:

  1. Mixed mode.  You can compile some modules with the "/clr" switch, and the compiler will use IJW interop to automatically thunk between native and managed code.  This is a great solution because the runtime characteristics of the existing code do not change, but you do have to design carefully because the native-managed transitions are not free and can add up.
  2. Pure mode.  Existing C++ code can be compiled to MSIL using the "/clr:pure" switch, yielding code that is pure .NET MSIL code, but it's not safe, verifiable code.  This approach means you don't pay the price for native-manage context switching, but it does have the annoying habit of changing the runtime characteristics (e.g., performance) of your existing code since your existing code is no longer being executed as native code.

Focusing back on .NET CF, I want to point out that option 1 is not supported by the Compact Framework today; there is no IJW in .NET CF.  Perhaps it's possible that the .NET CF and VC++ teams can collaborate on building out this technology some time in the future, but it is a substantial amount of work.  Option 2 is probably less work, since the .NET CF does support unsafe code today, but I know from experience that it doesn't always provide enough runtime fidelity as compared to pure native code to meet folks' needs.

So, back to my question: in which of these two scenarios is it more important to reuse existing code with .NET CF? Or do you think both are required for your success? Or are there other reuse scenarios I'm not considering?

Second is inability to migrate to managed world instantly because of a large investment in the existing code and a lack of free resources. Currently there is no migration path but complete rewrite. p/invoke will save maybe 5% of our code.

This comment raises two questions in my head.  First, why are you trying to get to the managed world? What are the benefits of this code running in the managed world that you aren't able to realize with the code running in the native world?  Secondly, why is p/invoke a 95% rewrite for you? That's a surprisingly high figure.

Third is that with C++/CLI you can easily use code written by C++ devs which are not aware of .Net existence. No learning curve for them at all.

Okay, apologies in advance for being outright controversial here, but I have talked to a lot of customers, and I've yet to talk to a single customer that has been unsuccessful in getting their C++ developers to be productive with C# in a very short period of time.  C++ developers already use arguably the most gnarly mainstream programming language, which tends to make it easier for them (as compared to other kinds of programmers) to pick up new languages quickly.  I would argue that the majority of the learning curve here is about the managed code platform, not the programming language you're using to talk to the platform.  This is the learning curve you need to traverse no matter what language you choose for .NET CF.  Of course, this is just one guy's view, so I'd love to hear other views.  :)