FileNotFoundException al deserializar XML

Question

Recientemente hemos empezado a ver FileNotFoundException lanzados esporádicamente mientras se deserializa XML. El mensaje es que no se puede encontrar el ensamblaje temporal utilizado para asignar el código XML al código. Desde el documento this parece que esto puede suceder cuando el Framework .NET no puede crear este archivo (sin embargo, la razón por la cual no se captura, incluso en la excepción interna).

Aquí es la excepción:

Type : System.IO.FileNotFoundException, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 
Message : Could not find file 'C:\Documents and Settings\user\Local Settings\Temp\c5_nfoko.dll'. 

El nombre del archivo es diferente en cada error, pero el error es siempre el mismo, que se origina a partir de aquí (pila de llamadas completa en la parte inferior):

at System.Xml.Serialization.XmlSerializer.GenerateTempAssembly(XmlMapping xmlMapping, Type type, String defaultNamespace) 
at System.Xml.Serialization.XmlSerializer..ctor(Type type, String defaultNamespace) 
at System.Xml.Serialization.XmlSerializer..ctor(Type type) 

Cuando el CSharpCodeGenerator intenta generar el ensamblaje. Hemos estado utilizando este código en producción durante años y ha sido muy estable. Simplemente comenzó a fallar en la última semana más o menos. Nos hemos preguntado si podría tener algo que ver con la última versión Microsoft security patch, ya que afecta a la versión de nuestro código en .NET 2.0 y .NET 4.0 en múltiples sistemas operativos (XP y Server 2003).

El error es esporádico y ejecutar el proceso de nuevo generalmente hace que desaparezca. Esta es una aplicación de línea de comando de un solo subproceso que recupera archivos y los inserta en una base de datos.

No he podido encontrar a nadie más con el mismo problema, pero no está aislado en la misma línea de código, tenemos un par de lugares que usan el código System.Xml.Serialization y hemos visto este error de cada. Este código tampoco es algo que hayamos cambiado recientemente.

La otra publicación más cercana que puedo encontrar es this una.

En nuestra QA VM no hay un antivirus, así que no creo que sea un problema. También hemos visto este problema tanto en nuestro entorno alojado como en un sitio de cliente separado.

Hemos tratado:

1. La limpieza de este directorio temporal
2. permisos comprobando en el directorio temporal (el usuario es administrador local en la caja)
3. Generación de XmlSerializers.dll mediante el uso y la implementación de sgen.exe a la carpeta de la aplicación (el problema persiste como si .NET Framework no quisiera usar estos ensamblajes).

Si alguien tiene alguna idea o sugerencia que pueda ser útil.

pila de llamadas completa:

Type : System.IO.FileNotFoundException, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 
Message : Could not find file 'C:\Documents and Settings\user\Local Settings\Temp\c5_nfoko.dll'. 
Source : mscorlib 
Help link : 
FileName : C:\Documents and Settings\user\Local Settings\Temp\c5_nfoko.dll 
FusionLog : 
Data : System.Collections.ListDictionaryInternal 
TargetSite : Void WinIOError(Int32, System.String) 
Stack Trace : at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) 
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy) 
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share) 
at Microsoft.CSharp.CSharpCodeGenerator.FromFileBatch(CompilerParameters options, String[] fileNames) 
at Microsoft.CSharp.CSharpCodeGenerator.FromSourceBatch(CompilerParameters options, String[] sources) 
at Microsoft.CSharp.CSharpCodeGenerator.System.CodeDom.Compiler.ICodeCompiler.CompileAssemblyFromSourceBatch(CompilerParameters options, String[] sources) 
at System.CodeDom.Compiler.CodeDomProvider.CompileAssemblyFromSource(CompilerParameters options, String[] sources) 
at System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, XmlSerializerCompilerParameters xmlParameters, Evidence evidence) 
at System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, XmlSerializerCompilerParameters parameters, Assembly assembly, Hashtable assemblies) 
at System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, String location, Evidence evidence) 
at System.Xml.Serialization.XmlSerializer.GenerateTempAssembly(XmlMapping xmlMapping, Type type, String defaultNamespace) 
at System.Xml.Serialization.XmlSerializer..ctor(Type type, String defaultNamespace) 
at System.Xml.Serialization.XmlSerializer..ctor(Type type) 

Answer 1

que tenía casi el mismo problema con ASP.NET. La razón es que las DLL temporales escritas en esa carpeta se recuerdan en alguna parte, tal vez en referencias de otras DLL temporales.

La solución es eliminar todos los archivos en la carpeta C:\Documents and Settings\user\Local Settings\Temp. Es probable que algunos de ellos estén bloqueados y necesite eliminar archivos en algunas iteraciones porque los archivos bloqueados son probablemente la fuente de un problema (según mi experiencia). Cuando la carpeta temporal está vacía, todo funciona de la manera prevista (al menos para mí).

Answer 2

El serializador XML de Microsoft es muy malo en sí mismo.La excepción que recibe es que .NET genera el ensamblaje sobre la marcha cada vez que crea un nuevo serializador XML. Para evitar esto tanto como sea posible, implemente un diccionario con la clave del tipo que intenta serializar y el serializador XML como valor. Este tipo de almacenamiento en caché le permitirá encontrar esta excepción de primera oportunidad solo la primera vez que serialice un tipo desconocido.

Eche un vistazo al sitio web de Microsoft MSDN, XmlSerializer Class. Hay un párrafo que te dice lo que acabo de decir.