【问题标题】:.NET 4.0 application on network share causes SecurityException网络共享上的 .NET 4.0 应用程序导致 SecurityException
【发布时间】:2010-04-27 21:54:05
【问题描述】:

今天我在尝试远程调试为 .NET 4.0 运行时构建的应用程序时遇到了一个奇怪的问题。

应用程序驻留在网络共享上并由远程计算机执行。但是,由于 System.Configuration.ConfigurationManager.GetSection() 方法中的权限需求引发了 SecurityException,因此应用程序每次在加载期间都会崩溃。我没有检查基类库中的其他权限要求是否也会导致安全异常,但在所有情况下,新 CLR 都不应该发生这种情况。

应用程序在完全信任的情况下运行(在调试时检查它,并且像往常一样,对于 CLR 4.0 中的 Intranet 应用程序必须始终如此),所以我不知道在这种情况下权限需求如何导致异常。当针对 3.5 SP1 运行时(默认情况下首次引入对网络共享应用程序的完全信任)构建时,一切都按预期运行。

我粘贴了下面的示例代码。非常感谢任何帮助。

using System;
using System.Configuration;

namespace ConsoleApplication1
{
public sealed class AssetsSection : ConfigurationSection
{
    private static readonly ConfigurationProperty           s_propPath;
    private static readonly ConfigurationPropertyCollection s_properties;

    static AssetsSection()
    {
        s_propPath = new ConfigurationProperty("path", typeof(String));

        s_properties = new ConfigurationPropertyCollection()
        {
            s_propPath
        };
    }

    public static AssetsSection Get()
    {
        return (AssetsSection) ConfigurationManager.GetSection("test/assets");
    }

    protected override ConfigurationPropertyCollection Properties
    {
        get
        {
            return s_properties;
        }
    }

    public String Path
    {
        get
        {
            return (String) base[s_propPath];
        }
        set
        {
            base[s_propPath] = value;
        }
    }
}

class Program
{
    static void Main(String[] args)
    {
        Console.WriteLine(AssetsSection.Get().Path);

        Console.ReadLine();
    }
}
}

还有 App.config 文件;

<?xml version="1.0"?>
<configuration>
<configSections>
    <sectionGroup name="test">
        <section name="assets" type="ConsoleApplication1.AssetsSection, ConsoleApplication1"/>
    </sectionGroup>
</configSections>

<startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0,Profile=Client"/>
</startup>

<test>
    <assets path="..\Assets"/>
</test>
</configuration>

【问题讨论】:

  • 为什么要为 .NET 4.0 构建,却强制它运行旧版本的 CLR?
  • 抱歉,我从测试代码中粘贴了错误的配置文件。我编辑了这个问题。但是,问题当然仍然存在。

标签: c# .net clr .net-4.0 securityexception


【解决方案1】:

尝试先加载配置并打开您的部分:

Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
AssetsSection configSection = (AssetsSection)config.GetSection("test/assets");

我在使用 .NET 4 时遇到了同样的问题,这对我有用。

【讨论】:

  • 非常感谢蒂莫。它也对我有用。但我认为这是 .NET 4.0 中的一个错误。
  • 请注意,虽然这可以解决异常,但存在性能问题:反序列化的 xml 未缓存,并且每次调用 OpenExeConfiguration() 时都会发生。使用 GetSection() 的“正确”(错误)方式缓存部分 XML,并将在后续调用中重用它。这可能会也可能不会影响您应用的性能,具体取决于它对性能的敏感程度以及您调用 OpenExeConfiguration 的频率。
【解决方案2】:

这是由于从网络共享运行应用程序时 .NET 4.0 中的一个已知错误。

以下代码因 SecurityException 而失败。请注意,仅当您为该部分定义了自定义类型时,它才会失败,如本例AssetsSection

ConfigurationManager.GetSection("test/assets");

Timo 提出的解决方案建议是使用不同的 API。另一种解决方案是应用微软提供的补丁。

该错误和相关的修补程序在KB2580188 下归档。

【讨论】:

    【解决方案3】:

    如果您添加自己的类来映射部分,如下所示:

    [XmlRoot("Interface")]
    public class MySectionClass
    {
        [XmlAttribute()]
        public string MyAttr1
        {
            get;
            set;
        }
    
        public string MyAttr2
        {
            get;
            set;
        }
    }
    

    您可以使用此代码:

    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);
    

    【讨论】:

      【解决方案4】:

      我在这里推测,但我怀疑是您的配置文件不受信任。

      在您的情况下,您的配置文件引用了一个类型 ConsoleApplication1.AssetsSection,该类型没有可用作证据的强名称。

      您能否提供更多详细信息和确切的错误消息。

      【讨论】:

      • 我有同样的问题,我的应用配置看起来像这样,我仍然有问题
      猜你喜欢
      • 2014-01-08
      • 2013-11-25
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-09-05
      • 2012-10-06
      • 1970-01-01
      相关资源
      最近更新 更多