Aujourd'hui, j'ai eu un problème étrange tout en essayant de déboguer à distance une application conçue pour le .NET 4.0 Runtime.
L'application réside sur un réseau de réseau et exécuté par une machine distante. Toutefois, l'application se bloque à chaque fois lors de la charge en raison d'une conforme SecurityException soulevée par une demande d'autorisation dans la méthode System.Configuration.ConfigurationManager.Getsection (). Je n'ai pas vérifié si d'autres demandes d'autorisation dans la bibliothèque de la classe de base provoquent également une exception de sécurité, mais dans tous les cas, cela ne devrait pas se produire avec le nouveau CLR.
L'application est en pleine confiance (vérifiée Tout en débogage et comme d'habitude, cela doit toujours être toujours vrai pour les applications intranet dans la CLR 4.0), je suis donc désemparé en quoi une demande d'autorisation peut provoquer une exception dans ce cas. Lorsqu'il est construit contre le point d'exécution 3.5 SP1 (qui a d'abord introduit la confiance totale des applications partagées réseau par défaut) Everythings fonctionne comme prévu.
J'ai collé le code de l'échantillon ci-dessous. Toute aide est grandement appréciée. et le fichier app.config;
4 Réponses :
Je spécule ici, mais je soupçonne que c'est votre fichier de configuration qui n'a pas confiance.
Dans votre cas, votre fichier de configuration fait référence à un type Pouvez-vous fournir plus de détails et le message d'erreur exact. consoleApplication1.asseSection qui n'a pas de nom fort qui pourrait être utilisé comme preuve.
J'ai le même problème, mon application d'application ressemble à ceci et j'ai toujours le problème
Essayez d'abord de charger la configuration et ouvrez votre section sur celle-ci:
Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
AssetsSection configSection = (AssetsSection)config.GetSection("test/assets");
Merci beaucoup timo. Cela a également fonctionné pour moi. Mais je suppose que c'est un bug de .NET 4.0.
Notez que, même si cela fonctionne à proximité de l'exception, il y a un problème de performance: le XML désérialisé n'est pas mis en cache et se produit chaque fois que vous appelez OpenExeconfiguration (). La "bonne" (buggy) en utilisant la getection () cache la section XML et la réutilisera en appels ultérieurs. Cela peut ne pas affecter les performances de votre application, en fonction de la manière dont la performance est sensible et la fréquence à laquelle vous passez des appels à OpenExeconfiguration.
Si vous ajoutez votre propre classe à mapper la section comme celle-ci:
ConfigurationSection configSection =
ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None).
GetSection("MySection");
XmlSerializer xs = new XmlSerializer(typeof(MySectionClass));
XmlDocument xdoc = new XmlDocument();
xdoc.LoadXml(configSection.SectionInformation.GetRawXml());
XmlNodeReader xnr = new XmlNodeReader(xdoc.DocumentElement);
MySectionClass section = (MySectionClass)xs.Deserialize(xnr);
Ceci est dû à un bogue connu dans .NET 4.0 lors de l'exécution de l'application à partir d'une part de réseau.
Le code suivant échoue avec une exception SecurityException. Notez que cela échoue uniquement lorsque vous avez défini un type personnalisé pour la section comme dans cet exemple une solution est la suggestion de la solution par TIMO pour utiliser une API différente. Une autre solution consiste à appliquer le patch fourni par Microsoft. Le bogue et le correctif associé est déposé sous Kb2580188 . actifsection :
Pourquoi construisez-vous pour .NET 4.0 mais force-le à gérer une ancienne version du CLR?
Désolé j'ai collé le mauvais fichier de configuration de mon code de test. J'ai édité la question. Cependant, le problème reste toujours bien sûr.