如何在部分信任环境中使用我的 app.config 的 system.net 部分？答案

【问题标题】：How can I use the system.net section of my app.config in a partial trust environment?如何在部分信任环境中使用我的 app.config 的 system.net 部分？
【发布时间】：2009-02-18 12:22:37
【问题描述】：

我有一个使用 clickonce 部署的 WCF 应用程序。它使用 https 连接到我的服务器，一切正常

由于以下代码，我在需要时使用默认代理：

  <configSections>
    <sectionGroup name="system.net" type="System.Net.Configuration.NetSectionGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <section name="defaultProxy" type="System.Net.Configuration.DefaultProxySection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
    </sectionGroup>
  </configSections>
  <system.net>
    <defaultProxy useDefaultCredentials="true"/>
  </system.net>

在完全信任模式下，一切正常

现在，如果我将安全设置设置为部分信任，如果不涉及代理，它确实可以正常工作，但如果我尝试在公司环境中启动我的软件，代理不再自动检测到。

据我了解：

在部分信任环境中不再解析 configSection，除非设置了 requirePermission 属性，如下所示：

<section requirePermission="false" name="defaultProxy">

设置此属性会引发带有以下错误消息的 System.Configuration.ConfigurationException：

部分或组名“defaultProxy” 已经定义了。对此的更新可能只发生在配置定义的级别。

'defaultproxy' 部分确实已经在 machine.config 文件中定义了：

   <section name="defaultProxy" type="System.Net.Configuration.DefaultProxySection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>

但是，只要未设置 requirePermission，这似乎不是问题。换句话说，似乎错误消息应该改为：

部分或组名“defaultProxy” 已使用另一个 requirePermission 设置定义。对此的更新可能只发生在配置定义的级别。

有人遇到过同样的问题吗？是否可以在部分信任模式下静默使用 WCF 应用程序中的默认代理？我也尝试以编程方式设置代理，但没有成功

System.Net.WebProxy proxy = new WebProxy();
proxy.UseDefaultCredentials = true;
WebRequest.DefaultWebProxy = proxy;

wshttpbinding 的 useDefaultWebProxy 属性是从一开始就直接设置的，但在部分或完全信任环境中，如果没有正确定义“system.net.defaultProxy”部分，似乎不起作用：

   <binding name="WebBinding" useDefaultWebProxy="true">

我想我可以要求我的客户更新他们的本地 machine.config 文件以添加所需的 defaultProxy useDefaultCredentials="true"，但这绝对不会简化部署。

【问题讨论】：

标签： .net wcf proxy code-access-security partial-trust

【解决方案1】：

我认为这是一个已知问题，可能与私钥传输有关。这里有一个 MS Connect 条目：

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=354646

我希望我已经正确理解了这个问题。如果您的问题是这个错误的结果，那么看起来目前还没有 ETA 修复。但是，可能存在与手动请求凭据相关的解决方法。显然这并不理想，但它可能会在您部署到生产系统之前为您提供另一种选择。

这里的 MSDN 论坛上还有其他讨论：

http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/c19b726b-573b-4157-91fd-051724f04180/

【讨论】：

【解决方案2】：

或者，如果在公司环境中工作，您可以尝试找到所需的权限以使您的应用程序正常工作。所以不是完全信任，而是更具体的代码访问安全策略。然后通过在企业级别/用户级别设置的组策略设置该策略。

【讨论】：