FileNotFoundException durante la deserializzazione di XML

Question

Abbiamo iniziato recentemente a vedere il numero FileNotFoundException che viene lanciato sporadicamente durante la deserializzazione di XML. Il messaggio è che l'assembly temporaneo utilizzato per eseguire il mapping dall'XML al codice non può essere trovato. Dal documento this sembra che questo possa accadere quando questo file non può essere creato da .NET Framework (tuttavia il motivo per cui non viene catturato nemmeno nell'eccezione interna).

Qui è l'eccezione:

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'. 

Il nome del file è diverso su ogni errore, ma l'errore è sempre lo stesso, proviene da qui (stack completo in basso):

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) 

Quando il CSharpCodeGenerator tenta di generare l'assembly. Stiamo usando questo codice in produzione da anni ed è stato molto stabile. Ha appena iniziato a fallire nell'ultima settimana o giù di lì. Ci siamo chiesti se potesse avere nulla a che fare con l'ultimo Microsoft security patch in quanto influenza la versione del nostro codice in .NET 2.0 e .NET 4.0 su più sistemi operativi (XP e Server 2003).

L'errore è sporadico e l'esecuzione del processo di solito causa la sua scomparsa. Questa è un'applicazione a riga di comando a thread singolo che recupera i file e li inserisce in un database.

Non sono stato in grado di trovare nessun altro con lo stesso problema, ma non è isolato per la stessa riga di codice, abbiamo un paio di posti che usano il codice System.Xml.Serialization e abbiamo visto questo errore da ciascuno. Anche questo codice non è qualcosa che abbiamo cambiato di recente.

L'altro post più vicino che riesco a trovare è this uno.

Sulla nostra VM QA non ci sono scanner antivirus quindi non penso che sia un problema con quello. Abbiamo anche riscontrato questo problema sia nel nostro ambiente ospitato che in un sito client separato.

Abbiamo cercato:

1. Ripulire questa directory temp
2. permessi di verifica della directory temp (utente è admin locale sulla scatola)
3. Generazione di XmlSerializers.dll utilizzando sgen.exe e la distribuzione alla cartella dell'app (il problema persiste come se .NET Framework non volesse utilizzare questi assembly).

Se qualcuno ha idee o suggerimenti che potrebbero essere utili.

callstack 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

ho avuto quasi lo stesso problema con ASP.NET. La ragione è che le DLL temporanee scritte in quella cartella sono ricordate da qualche parte, forse in riferimenti da altre DLL temporanee.

La soluzione è eliminare tutti i file nella cartella C:\Documents and Settings\user\Local Settings\Temp. Alcuni di questi sono probabilmente bloccati ed è necessario eliminare i file in poche iterazioni perché i file bloccati sono molto probabilmente la fonte di un problema (dalla mia esperienza). Quando la cartella temporanea è deselezionata, tutto funziona come previsto (almeno per me).

Answer 2

Il serializzatore XML di Microsoft è molto cattivo di per sé.L'eccezione che si ottiene è perché .NET genera l'assembly al volo ogni volta che si crea un nuovo serializzatore XML. Per evitare quanto possibile, implementare un dizionario con la chiave del tipo che si sta tentando di serializzare e il serializzatore XML come valore. Questo tipo di memorizzazione nella cache consentirà di riscontrare questa prima eccezione solo la prima volta che si serializza un tipo sconosciuto.

Dai un'occhiata al sito Web MSDN di Microsoft, XmlSerializer Class. C'è un paragrafo che ti dice quello che ho appena detto.