When trying to serialize a type (a generic List<T> which T is a class marked with XmlRootAttribute) into XML using XmlSerializer, a FileNotFoundException is thrown (sometimes) and serialization fails.
It seems that XmlSerializer tries to create a temporary file with a random file name in the Temp folder of user under which the application is running, but the file gets deleted somehow.
Anyone seen this? Any workarounds?
XmlSerializer works by generating code to do the serialization/deserialization, and storing this in a temporary assembly. (This approach gives good performance for repeated serialization/deserialization but (traditionally) shockingly awful performance for the first run)
To help mitigate the shocking performance, from VS2005 onwards (and earlier using less well known techniques), you can explicitly create the serialization assembly at build time and ship it with your main assembly.
If you don't create/ship the serialization assembly, then the framework tends to throw an exception when it's looking for it, though normally it catches the exception, builds the assembly on the fly, and gets on with things. If you're running under a debugger, with 'break-on-throw' set though, it can be a bit alarming to have the FileNotFound exception being thrown deep in the bowels of the framework.
Are you sure that the FileNotFound exception is directly associated with the serialization failure you're seeing? Have you tried including the serialization assembly explicitly?
If you build with Visual Studio, there is an interesting option for you in the project properties. On the Build-tab you chan choose to Generate Serialization Assemby (Yes, No, Auto). If I remember correctly, I did not succeed in generating this assembly with 'Yes' to get rid of that exception. But once I had the impression that setting the option to 'No' led the build to not try searching for such an assembly, so there was no frustrated FileNotFound-Exception anymore. Anyway, as you already said, the exception is more a cosmetical problem. You could think about suppressing it (configure via Debug/Exceptions... in Visual Studio), at least for the case that it is handled.
The last possibility here is that there is a big in the XML Serialization runtime. These were more common years ago, but it's possible there are still a few. What could happen was, given perfectly legal XML Serialization markup on your C# or VB (or other) code, creating an XmlSerializer for the type would cause illegal code to be created for the JIT-compiled serialization assembly. The compile would choke and die, and then loading the assembly would throw. Usually with a filename of rfuieuy267.dll or something similar.
And there was a secret incantation you could utter to tell the XmlSerialization engine to preserve the .cs code it generated, but I don't remember what it is now. It was not documented; i only learned of it when working with the MS Engineers debugging one of these problems. But I'll bet you can find it in googlespace.