XmlSerializer FileNotFoundException

[Dan]

I frequently serialize class instances with XmlSerializer. It works BUT...

Whenever I'm debugging and (via the Debug->Exceptions dialog) and enable
breaking whenever Common Language Runtime Exceptions are 'Thrown', I ALWAYS
get a FileNotFoundException instantiating a serializer:

XmlSerializer serializer = new XmlSerializer ( myClass.GetType () );

If I go back into the Exceptions dialog, Reset All and step over that line
of code it works, I re-enable Thrown exceptions and can continue. So, it's
not a show-stopper, but it's a pain to always have to be toggling this off
and on.

Is there anything I can do about this?

 

[Jeroen Mostert]

I frequently serialize class instances with XmlSerializer. It works BUT...

Whenever I'm debugging and (via the Debug->Exceptions dialog) and enable
breaking whenever Common Language Runtime Exceptions are 'Thrown', I ALWAYS
get a FileNotFoundException instantiating a serializer:

XmlSerializer serializer = new XmlSerializer ( myClass.GetType () );

If I go back into the Exceptions dialog, Reset All and step over that line
of code it works, I re-enable Thrown exceptions and can continue. So, it's
not a show-stopper, but it's a pain to always have to be toggling this off
and on.

Is there anything I can do about this?

In general, no -- try this with ASP.NET some time, you'll probably get
multiple framework exceptions (handled, of course, but that's not the
point). It's fairly painful. Thankfully, there are developers at Microsoft
who think this is painful too, so they do put some effort into making sure
the framework throws no exceptions in unexceptional cases. It's not perfect
yet, though.

However, in this very particular case, there probably *is* something you can
do. XmlSerializer generates temporary files and assemblies as it's producing
serializers. There are various things that can go wrong as it's doing so,
even if it manages to recover. You can avoid most problems with them if you
generate serializers up front (with sgen.exe or by checking the appropriate
project option) rather than have them produced at runtime. Not usable in all
scenarios, but when it is it's a good idea (not having to compile things at
runtime also gives a performance boost).

There's also this neat article:
http://msdn.microsoft.com/en-us/library/aa302290.aspx

It's old, but most of it still applies.