Tag Archives: .NET

Cannot deserialize XBF metadata type list as NullableBoolToBoolConverter was not found in namespace

I was trying to get something working last night and kept hitting this exception when my app was trying to InitializeComponent() at one point.


First-chance exception at 0x750D1D4D in App1.exe: Microsoft C++ exception: Platform::COMException ^ at memory location 0x037CDDC0. HRESULT:0x802B000A The text associated with this error code could not be found.

WinRT information: Windows.UI.Xaml.Markup.XamlParseException: The text associated with this error code could not be found.

Cannot deserialize XBF metadata type list as ‘NullableBoolToBoolConverter’ was not found in namespace ‘WinRTXamlToolkit.Converters’. [Line: 0 Position: 0]

at Windows.UI.Xaml.Application.LoadComponent(Object component, Uri resourceLocator, ComponentResourceLocation componentResourceLocation)

All this seemed complete and utter bogus, since NullableBoolToBoolConverter was obviously there and it would work perfectly well in other projects or solution configurations, so let’s look what was happening.

  • NullableBoolToBoolConverter is defined in WinRTXamlToolkit – a .NET Class Library that I’d typically build as Any CPU. It has a ton of controls, converters and other such goodies and of course it typically works just fine.
  • NullableBoolToBoolConverter is used in WinRTXamlToolkit.Debugging – another .NET Class Library that has an in-app XAML visual tree debugger tool – essentially a TreeView control that displays information about the visual tree of your application – hierarchy of UI elements and their properties. The main control in the library uses NullableBoolToBoolConverter and it normally works when used from a .NET Windows Store app.
  • The problem is that WinRTXamlToolkit.Debugging is a .NET Class Library and there is still a small, but important range of WinRT XAML apps written in C++ that can’t use it, so I created a managed WinRT component library – WinRTXamlToolkit.Debugging.WinRTProxy that C++/CX projects can reference. It’s fairly straightforward to do it seems – you just create a proxy class in the WinRT Component library that has methods that invoke methods in the referenced class library (WinRTXamlToolkit.Debugging) and now you can use it from C++/CX. I prefer to keep WinRTXamlToolkit.Debugging a regular .NET class library because WinRT Components have limitations that would limit the APIs I currently have in WinRTXamlToolkit.Debugging. The proxy methods in the WinRTProxy library still have these limitations, but at least I can use it from a native app. The problem is that it wouldn’t work and keep giving me that exception, so what’s up?

It turns out WinRT XAML generates these files – XamlTypeInfo.g.cs that allow the XAML parser to see the types it can use and I noticed that file was missing in the obj folder of WinRTXamlToolkit.Debugging.WinRTProxy. To get it to generate I simply added one empty UserControl to WinRTXamlToolkit.Debugging.WinRTProxy and everything started working fine! Weird but it works. So now I’m left with figuring out how to wrap this all as a NuGet component with native versions of the .NET libraries, since I’ve previously only packaged Any CPU binaries…

Tagged , , , , , ,

A path from C/C++ to C# and back to C++

About ten years ago I started my first full time programming job. I was working on some business software written in C/C++. I say C/C++ instead of just C++ because it was written mostly in C with classes – with perhaps a few cases of inheritance or actually even only few classes – it used structs in many places to group some methods together the same way you would use classes today. The code was fairly complicated and it was just aging. The standard C libraries it used were not very rich, so if you wanted to code up something fairly straightforward – you had to dig through a lot of documentation looking for something basic only to end up implementing that list class yourself. We were using a Watcom compiler at that time and trying out Borland C++ Builder for some side projects showed it was a great improvement in that VCL provided a lot of great wrapper classes for Windows APIs making things easier. Two years later we were looking into rewriting our application or at least starting a new version and considering which tools to use – basically trying to choose between Borland C++ and C#. I was on the C++ side – it was a fairly known language, more predictable and providing intuitively higher performance, while C# was at version 1.1 and had lots of great libraries, but a bit foreign and why would anyone want to go away from the fun of using pointers, managing object lifetimes and relying on some garbage (collector)? Well, I lost – Microsoft seemed to be focusing on supporting C# and in the end it turned out to be a lot more productive than C++.

Fast forward 8 years and Microsoft says – in Windows 8 you can code using C#/VB, JavaScript or C++. Well, the word on the street is that it is so that programmers fluent in any of these languages will be able to code applications for Windows, so I guess I will stick with C#. Maybe I will look at HTML5, JS and CSS, since these seem to be getting most traction, I thought. Now, having found some limitations in the .NET/WinRT stack I have a feeling like the C++/DirectX route is the most attractive. The .NET stack might make you more productive than the JS or C++ – especially if you have been coding in C# for the last eight years and perhaps HTML5 has better graphics performance or some other interesting features, but it feels like learning C++/DirectX on top of C#/WinRT is what would allow me to cover most scenarios for writing Metro Style Apps™, so especially with some experience working on the test team for the DirectX wrappers in the Windows API Code Pack – I am hoping to have an easier start in diversifying my skills.

Continue reading

Tagged , , , , , ,