Hello,

first of all thanks for the great work you are doing with ILSpy: I really love it.
I have found a bug with the baml decompiler (even with the current stable version of ILSpy - 2.1.0.1603), which happens whenever you try to decompile some baml (more specifically, the ones contained within some of the Visual Studio 2010 internal dlls).

Here is the full stack trace for the exception:

System.FormatException: Input string was not in a correct format.
at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
at System.Byte.Parse(String s, NumberStyles style, NumberFormatInfo info)
at Mono.Cecil.AssemblyNameReference.Parse(String fullName)
at ILSpy.BamlDecompiler.CecilTypeResolver.GetTypeByAssemblyQualifiedName(String name)
at Ricciolo.StylesExplorer.MarkupReflection.TypeDeclaration.get_Type()
at Ricciolo.StylesExplorer.MarkupReflection.XmlBamlReader.get_NamespaceURI()
at Ricciolo.StylesExplorer.MarkupReflection.XmlBamlReader.get_Prefix()
at System.Xml.Linq.XContainer.ReadContentFrom(XmlReader r)
at System.Xml.Linq.XContainer.ReadContentFrom(XmlReader r, LoadOptions o)
at System.Xml.Linq.XDocument.Load(XmlReader reader, LoadOptions options)
at ILSpy.BamlDecompiler.BamlResourceEntryNode.LoadIntoDocument(IAssemblyResolver resolver, AssemblyDefinition asm, Stream stream)
at ILSpy.BamlDecompiler.BamlResourceEntryNode.LoadBaml(AvalonEditTextOutput output)
at ILSpy.BamlDecompiler.BamlResourceEntryNode.<>c__DisplayClass3.b__1()

Perhaps CecilTypeResolver should react silently to the exception and try to decompile with the information it already has?

Thanks a lot for your support.
Cheers