FileNotFoundException lors de la Desérialisation de XML
nous avons récemment commencé à voir FileNotFoundException est lancé de façon sporadique tout en désérialisant XML. Le message est que l'assemblage temporaire utilisé pour passer du XML au code ne peut pas être trouvé. À partir de document il semble que cela puisse se produire lorsque ce fichier ne peut pas être créé par le Framework .NET (cependant la raison pour laquelle n'est pas capturée même dans l'exception interne).
Voici l'exception:
Type : System.IO.FileNotFoundException, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
Message : Could not find file 'C:Documents and SettingsuserLocal SettingsTempc5_nfoko.dll'.
Le nom du fichier diffère sur chaque erreur, mais la d'erreur est toujours le même, il est originaire d'ici (plein de la pile en bas):
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)
quand le CSharpCodeGenerator tente de générer l'Assemblée. Nous utilisons ce code depuis des années et il est très stable. Ça a commencé à échouer la semaine dernière. Nous nous sommes demandés si cela pouvait avoir quelque chose à voir avec la dernière correctif de sécurité de Microsoft tel qu'il affecte la version de notre code dans .NET 2.0 et .net 4.0 sur plusieurs systèmes d'exploitation (XP et Server 2003).
L'erreur est sporadique et l'exécution du processus provoque généralement qu'il s'en aille. Il s'agit d'une seule application en ligne de commande filetée qui récupère les fichiers et les insère dans une base de données.
Je n'ai pas été en mesure de trouver quelqu'un d'autre avec le même problème, mais il n'est pas isolé à la même ligne de code, nous avons quelques endroits qui utilisent le System.Xml.Serialization code et nous avons vu cette erreur. Ce code n'est pas quelque chose que nous avons changé récemment.
Le plus proche de l'autre post, je trouve, c'est .
sur notre VM QA il n'y a pas de scanner de virus donc je ne pense pas que ce soit un problème avec cela. Nous avons également vu ce problème dans notre environnement hébergé et dans un site client distinct.
Nous avons essayé:
- nettoyer ce répertoire temporaire
- vérification des permissions sur le répertoire temp (l'utilisateur est l'administrateur local sur la boîte)
- Génération XmlSerializers.dll en utilisant sgen.exe et les déployer dans le dossier app (le problème persiste comme si le Framework .NET ne voulait pas utiliser ces assemblages).
Si quelqu'un a des idées ou des suggestions qui pourraient être utiles.
Complet de la pile:
Type : System.IO.FileNotFoundException, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
Message : Could not find file 'C:Documents and SettingsuserLocal SettingsTempc5_nfoko.dll'.
Source : mscorlib
Help link :
FileName : C:Documents and SettingsuserLocal SettingsTempc5_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)
2 réponses
j'ai eu presque le même problème avec ASP.NET. La raison est que les DLLs temp écrits dans ce dossier sont rappelés quelque part, peut-être dans des références d'autres DLL temp.
La solution est de supprimer tous les fichiers dans le C:\Documents and Settings\user\Local Settings\Temp dossier. Certains d'entre eux sont susceptibles d'être verrouillé et vous devez supprimer les fichiers en quelques itérations, car les fichiers verrouillés sont probablement la source d'un problème (de mon expérience). Lorsque le dossier temp est clair, tout fonctionne comme prévu à nouveau (au moins pour je.)
le serializer XML de Microsoft est très mauvais en soi. L'exception que vous obtenez est parce que .NET génère l'assemblage à la volée chaque fois que vous créez un nouveau serializer XML. Pour empêcher cela autant que possible, implémenter un dictionnaire avec la clé du type que vous essayez de sérialiser et le serializer XML comme valeur. Ce type de cache vous permettra de rencontrer cette exception de première chance seulement la première fois que vous sérialisez un type inconnu.
jetez un coup d'oeil sur le site MSDN de Microsoft,Classe XmlSerializer. Il y a un paragraphe qui vous dit ce que je viens de dire.