I'd like to go down the route of porting a WPF/Silverlight component to Windows 8. For a bit of context, the component is a real-time WPF Chart, which uses a mixture of WPF/XAML and bitmap rendering to achieve high performance.
I'd like the component to be Metro compatible, e.g. used in metro mode as well as desktop mode. I read a lot about creating C++/WinRT applications in Windows 8 as well as C#/XAML applications, but what are the differences between the two frameworks?
Are there limitations if you choose C#/XAML over C++/XAML? Also consider the porting from C#/Xaml in .NET4.0 to Windows8 would be far easier if I could stick to C#/XAML, however will I be able to create a fully featured Metro component using this method?
Your comments/suggestions appreciated.
Edit:
If you're voting to close this thread, please post a comment why. Its a valid question, has +6 votes, four answers and one favourite. Seems reasonable to keep it to me!
What I need to know is, are the feature sets for C# vs. C++ different. E.g. can I create a fully featured component in C#/Xaml to target both metro and desktop modes? Thanks - Dr. ABT 2012-04-05 16:19
I see the difference as a design choice, than a personal preference of language. Preference would be more related to VB vs C#. And generally it's the same differences you get in any application where you choose C++ or .NET.
C++ will give you faster startup times. IIRC, .NET 4.5 has auto NGENing abilities (not sure how it related to metro apps), so this may help mitigate typical slow startup times of .NET applications.
C++ will give you lower general memory usage as it does not use a garbage collector. This becomes increasingly more important on resource constrained devices such as tablets. IIRC, .NET 4.5 has more mitigations into GC pauses (which can cause the UI to studder), they are still a reality with managed code.
Since .NET and C++ use the same WinRT framework, there probably won't be too much difference in interacting with the XAML/WinRT platform (technically faster interacting with WinRT objects via C++ but the hit is really small), but of course your user code will generally be faster with C++ than .NET.
C++ is generally more difficult to reverse engineer, even when compared with obfuscated .NET code. Though sly thieves can steal your IP regardless.
Since .NET was created first for the convenience of the developer and developer productivity, you will have more convenience options in architecting your applications (eg, reflection based tools such as DI/IoC).
Iterating application code may be easier via .NET as .NET compiles quicker than C++, but correctly created C++ projects this can be mitigated substantially.
Pure .NET projects can support "Any CPU", which means your application can run on all supported WinRT platforms. C++ projects you will simply have to recompile to support ARM, x86/64. If you .NET application depends on a custom C++ component, you will have to compile for each architecture.
Because WinRT was created from the ground up to support many languages, my suggestion to devs that arent comfortable with C++ is to stick with .NET but explore areas that benefit from C++. Microsoft has done a great job with the /CX projections and most C# devs should be able to find their way around. My suggestion to C++ devs is to stick with C++ and get all the benefits of C++.
From a XAML perspective it becomes a language choice. The XAML UI stack is the same regardless of which code language you choose here. Depending on your goal of the app it might make more sense to use C++ if you need the benefits of what that language provides you.
We also have the ability to mix DirectX and XAML now in Win8 and that usually means C++ -- however with projects like SharpDX that still isn't totally valid (yes I realize you will be paying a performance hit in DirectX for wrapping in managed code...I'm just pointing out it can be done).
Your question seems to be about creating a re-usable component that can be used across the desktop and Metro. This may be somewhat challenging a bit depending on how you architect it because of how some changes were required to how resources (i.e., generic.xaml) are loaded from a file location versus an embedded resource.
The only advantage I can think of to use C++/XAML is if speed is important to your project. The advantage of C#/XAML is that is much more easier to code, especially if your project its in C# already.
By now there is no way to make an application that targets both the Metro and the desktop in Windows 8.
Hope this helps.
Well others may know more, but based on Microsoft's answer to a question I posed back around WinRT announcement time:
WinRT is a protocol and a set of Native APIs, allowing each language to remain true to its existing execution environment - Chakra for JavaScript, CLR for C# and the CRT/raw native code for C++.
That suggests similar performance trade-offs to what we currently experience using the CLR vs. native code to access what is essentially a native code API (WinRT). But I look forward to seeing some empirical investigations into this to see just how different WinRT is.
