Discovered a Bug. Discovered it Fixed.
A strange bug hit me today. Well, it's not so much a bug as a badly reported error.
I was making a quick change to a class today - adding one property - and all of a sudden the whole application fell over. What was weird was the error being reported was a symptom of the problem, not the problem itself, so it took me a while to sort out.
In the cases when I'm adding an extra property to an existing class, generally I copy and paste a similar property and modify it to what's needed. All this looked fine, until I started the application and it fell over immediately. At startup I generate a set of shared pools to hold some XMLSerializers, so that we aren't hit repeatedly by slowdowns from the constructor for the XMLSerializer.
Anyway, I open my browser (it's a web app) and hit the site, and boom!
Unhandled Exception: System.IO.FileNotFoundException: File or assembly name -x8neg_3.dll, or one of its dependencies, was not found.
File name: "-x8neg_3.dll"
at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Boolean isStringized, Evidence assemblySecurity, Boolean throwOnFileNotFound, Assembly locationHint, StackCrawlMark& stackMark)
at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Boolean stringized, Evidence assemblySecurity, StackCrawlMark& stackMark)
at System.Reflection.Assembly.Load(AssemblyName assemblyRef, Evidence assemblySecurity)
at System.CodeDom.Compiler.CompilerResults.get_CompiledAssembly()
at System.CodeDom.Compiler.CompilerResults.get_CompiledAssembly()
at System.Xml.Serialization.Compiler.Compile()
at System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings)
at System.Xml.Serialization.XmlSerializer.GenerateTempAssembly(XmlTypeMapping xmlTypeMapping)
at System.Xml.Serialization.XmlSerializer..ctor(Type type, String defaultNamespace)
at System.Xml.Serialization.XmlSerializer..ctor(Type type)
It's fallen over in the constructor for the XMLSerializer, and can't seem to find the temp assembly that was generated. Wierd ass!
After a bit of hunting, and trying work out how adding one property (of type String) could have such a savage impact. After a while, I tracked it down - The DefaultValueAttribute that marked the property. I'd written the property (as I said above) by cutting and pasting an existing one. I forgot to update the DefaultValueAttribute of the property, and while I should have set it to vbNullString, I instead had it left at False (copied from a boolean property - whoops!).
So the DefaultValue has totally screwed the serializer, which is fair enough - but surely it should have errored there? Instead it seems the generation of the temp assembly failed silently, and then it threw it's main exception trying to lad an assembly that didn't exist.
So the next question is: Have they fixed this in Whidbey? Sure, I only discovered this today, but hopefully it's not too late to get it fixed for whidbey if they haven't already. Well, this was my first time really playing with the Exception Assistant, but..WOW! This was a much nicer error, and presented in a pretty cool way.
OK, so it's not as nice an error reported as there could be (more appropriate would have been 'DefaultValueAttribute of Type Boolean does not match Type String on Property XXX) but still, it's a bit more of a lead into what might be going on.
It would be nice, however, if it didn't report a C# error (CS0019) or talk in C# types (string and bool, not String and Boolean) while I'm sitting in VB code!
Listening to - the thing that should not be - metallica - (7:26)