XmlSerializer NullReferenceException in Constructor

Question

So,

Something which I though was rather common it turns out is not so common with our code and am now forced to investigate.  We have 3 primary developers running through VisualSVN (and subsequently tortoiseSvn on the back end) and it is somewhere near 500,000 lines of code for our software.  Every now and again, I would hit F5 to run the app and during the boot process of the application I would get these "catch on throw" breaks for the XmlSerializer causing a NRE in its constructor.  F5-ing past this seemed to ignore the problem and the code always.  I was recently informed that this does not happen on my boss's system.

This begs to light a problem with the "debugger" as perhaps I have something set that he doesn't, or vice versa. 

We have a rather simple class setup.  SerializableList<T>, and SerializableList.  Second descends from the first, and simply passes in "Object" as it's T parameter, since the second is for static methods primarily.  These methods/properties retain a list of serializers for given types, so for things that we are CONTANTLY serializing/desierializing in the course of application being run, we are not creating hundreds of xmlserializers for the same type.  (i did not write this, but so far haven't had any really issue with the design). 

From there I create an attributed [Serializable] class, and a descendent of the SerializableList<T> class and simply write a simple Save()/Load() method pair and forget all about it. 

However, now that this error is more regularly cropping up y boss wants me to investigate, as there should be no reason for "new XmlSerializer(typeof(mytype));" to raise an NRE.

I've included the stack trace which has always been something generally like this especially with the last section being somewhere in the visual studio architecture, but haven't a clue as to why or how to resolve.

Regards,

Jaeden "Sifo Dyas" al'Raec Ruiner

 	Microsoft.VisualStudio.DebuggerVisualizers.dll!Microsoft.VisualStudio.DebuggerVisualizers.DebugViewerShim.AssemblyResolver.CreateSig(System.Reflection.AssemblyName name, bool noVersion) + 0xab bytes	
 	Microsoft.VisualStudio.DebuggerVisualizers.dll!Microsoft.VisualStudio.DebuggerVisualizers.DebugViewerShim.AssemblyResolver.CreateSig(string assemblyName, bool noVersion) + 0x5d bytes	
 	Microsoft.VisualStudio.DebuggerVisualizers.dll!Microsoft.VisualStudio.DebuggerVisualizers.DebugViewerShim.AssemblyResolver.ResolveName(string fullAssemblyName, bool noVersion, bool cacheOnly) + 0x35 bytes	
 	Microsoft.VisualStudio.DebuggerVisualizers.dll!Microsoft.VisualStudio.DebuggerVisualizers.DebugViewerShim.AbstractAssemblyResolver.ResolveName(string fullAssemblyName, bool cacheOnly) + 0x31 bytes	
 	Microsoft.VisualStudio.DebuggerVisualizers.dll!Microsoft.VisualStudio.DebuggerVisualizers.DebugViewerShim.AbstractAssemblyResolver.ResolveName(string fullAssemblyname) + 0x2d bytes	
 	Microsoft.VisualStudio.DebuggerVisualizers.dll!Microsoft.VisualStudio.DebuggerVisualizers.DebugViewerShim.AbstractAssemblyResolver.ResolveHandler(object source, System.ResolveEventArgs resolveArgs) + 0x39 bytes	
 	mscorlib.dll!System.AppDomain.OnAssemblyResolveEvent(string assemblyFullName) + 0x82 bytes	
 	[Native to Managed Transition]	
 	[Managed to Native Transition]	
 	mscorlib.dll!System.Reflection.Assembly.nLoad(System.Reflection.AssemblyName fileName, string codeBase, System.Security.Policy.Evidence assemblySecurity, System.Reflection.Assembly locationHint, ref System.Threading.StackCrawlMark stackMark, bool throwOnFileNotFound, bool forIntrospection) + 0x2c bytes	
 	mscorlib.dll!System.Reflection.Assembly.LoadWithPartialNameInternal(string partialName, System.Security.Policy.Evidence securityEvidence, ref System.Threading.StackCrawlMark stackMark) + 0x6b bytes	
 	mscorlib.dll!System.Reflection.Assembly.LoadWithPartialName(string partialName, System.Security.Policy.Evidence securityEvidence) + 0x19 bytes	
 	System.Xml.dll!System.Xml.Serialization.TempAssembly.LoadGeneratedAssembly(System.Type type, string defaultNamespace, out System.Xml.Serialization.XmlSerializerImplementation contract) + 0x15a bytes	
 	System.Xml.dll!System.Xml.Serialization.XmlSerializer.XmlSerializer(System.Type type, string defaultNamespace) + 0x105 bytes	
 	System.Xml.dll!System.Xml.Serialization.XmlSerializer.XmlSerializer(System.Type type) + 0x7 bytes	
>	GI.Common.Lib.dll!SerializableList.GetSerializer<GI.Iris.Lib.Base_Objects.Passwords.PreviousPassword>() Line 34 + 0x57 bytes	C#
 	GI.Common.Lib.dll!SerializableList<GI.Iris.Lib.Base_Objects.Passwords.PreviousPassword>.WriteXml(System.Xml.XmlWriter writer) Line 51 + 0x56 bytes	C#
 	System.Xml.dll!System.Xml.Serialization.XmlSerializationWriter.WriteSerializable(System.Xml.Serialization.IXmlSerializable serializable, string name, string ns, bool isNullable, bool wrapped) + 0x45 bytes	
 	xvw-11cc!Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterPasswordHistoryList.Write1_PasswordHistoryList(object o) + 0x8d bytes	
 	[Native to Managed Transition]	
 	[Managed to Native Transition]	
 	System.Xml.dll!System.Xml.Serialization.TempAssembly.InvokeWriter(System.Xml.Serialization.XmlMapping mapping, System.Xml.XmlWriter xmlWriter, object o, System.Xml.Serialization.XmlSerializerNamespaces namespaces, string encodingStyle, string id) + 0x13f bytes	
 	System.Xml.dll!System.Xml.Serialization.XmlSerializer.Serialize(System.Xml.XmlWriter xmlWriter, object o, System.Xml.Serialization.XmlSerializerNamespaces namespaces, string encodingStyle, string id) + 0x194 bytes	
 	System.Xml.dll!System.Xml.Serialization.XmlSerializer.Serialize(System.IO.Stream stream, object o, System.Xml.Serialization.XmlSerializerNamespaces namespaces) + 0x4c bytes	
 	System.Xml.dll!System.Xml.Serialization.XmlSerializer.Serialize(System.IO.Stream stream, object o) + 0xb bytes	

---

"Never Trust a computer. Your brain is smarter than any micro-chip."
PS - Don't mark answers on other people's questions. There are such things as Vacations and Holidays which may reduce timely activity, and until the person asking the question can test your answer, it is not correct just because you think it is. Marking it correct for them often stops other people from even reading the question and possibly providing the real "correct" answer.

Answer 1

You seem to be stopping at first-chance exceptions. You should ignore those. What matters is "unhandled" exceptions.

---

John Saunders
WCF is Web Services. They are not two separate things.
Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
Use File->New Project to create Web Service Projects

Answer 2

actually we aren't stopping at first change exceptions. 

the current solution has been that when we get this error, to turn on the "generate" serialization assemblies in the app properties.  run it, then uncheck that setting, and everything works.  it is a flaw in the Reflection Emit code of the XmlSerializer that somehow decides to break randomly during development.  Similar to the windows forms designer when it latches on to certain assemblies for the toolbox and when you change a component you need to slap VS upside the head to get it to recognize the change.

Thanks Anyway,

J"SD"a'RR

---

"Never Trust a computer. Your brain is smarter than any micro-chip."
PS - Don't mark answers on other people's questions. There are such things as Vacations and Holidays which may reduce timely activity, and until the person asking the question can test your answer, it is not correct just because you think it is. Marking it correct for them often stops other people from even reading the question and possibly providing the real "correct" answer.