I recently replaced our System.Xaml-based BAML decompiler with a small add-in based on the XmlBamlReader by Cristian Ricciolo Civera, which he released on CodePlex under the MS-PL (last changed in November 2008 at the time of this writing). I adopted his code, extended it and fixed some bugs as well. His XmlBamlReader code and my wrapper around it, is re-released under the MS-PL.
Now you might be asking, why did we abandon System.Xaml and the Baml2006Reader released by Microsoft? The reasons are the following:
1. System.Xaml and Baml2006Reader are closed APIs. You put BAML in and get XAML out. Compared to having a transparent decompilation process, which is fully customizable, Baml2006Reader is a black box with very few knobs. So fixing bugs in the decompilation process and improving it is not very easy.
2. Baml2006Reader uses Reflection to load the assemblies needed for decompilation. This requires to put the whole decompilation into a separate AppDomain, which leads to more complex code and is a bit more resource-intensive. With the new API, we can simply use Mono.Cecil for reading the assemblies. Cristian implemented a very open and highly abstracted API, which also makes it easy to unit test the decompilation process.
3. As mentioned before Baml2006Reader uses Reflection, which unfortunately is not read-only. This brings us straight to the main reason why we ripped out Baml2006Reader: It executes static constructors to register dependency properties and the like, which results in a possible security-hole. For more details see issue #161. The following screenshot illustrates the problem:
This could be used to execute harmful code while the user decompiles BAML files. Using Mono.Cecil no decompiled code is executed.
I am very proud that we now have a better opportunity to implement BAML decompilation and I want to thank Cristian for his work and I am glad to be able to continuously maintain and improve his code.
If you face any issues with the new BAML decompiler add-in, I'd be glad to hear about them.