As of today (Feb CTP), Visual C++ projects cannot have XAML in them as C# and VB projects can. Of course, this does not mean that you cannot target Avalon using C++, and if you have read my previous blog entries, you’d have seen a couple of ways how that can be done. To put things in the right perspective, let’s see what options we have and their pros and cons.
- 100% procedural code – This would allow you to develop Avalon apps with just VC++ and no other tool. Disadvantages would be a lack of UI-Logic separation, unsuitability for designing complex UIs, and increased lines of code. Advantages are you can use C++, and needn’t depend on VC# or any other tool.
- C++ code dynamically loading XAML – You still stay within VC++ and are not dependent on other tools. You also achieve UI-Logic separation, because the UI stuff is in the XAML. But your apps would have loosely distributed XAML file dependencies, and any XAML corruption would mean trouble. And while you have reduced LOC, you still need to write code to wire the XAML elements with control variables.
- Put the XAML in C#, derive a class in C++/CLI – This is a pretty decent option right now. There is full UI-Logic separation, and you can use Cider to design your XAML. The elements are wired to your code by the compiler and LOC is further reduced. Disadvantage is the dependency on a temporary C# project to create the XAML, and the need to put that in a DLL.
Of course, in future, if direct support for XAML is added to VC++ (as I believe it will), then that’d be our best option. But until then, we are not out of the game, which is a good thing I say 🙂