WCF-WSDL或预编译代理

这是B2B场景，一个客户端（至少目前是这样）

服务器环境： WCF服务，IIS6，.NET v3.5

客户端环境： 开发商店是.NET2.0/VS2005。将调用我的WCF服务

问题：我应该
（a） 为客户端打开WSDL gen（出于安全原因不可取）
（b） 将WSDL文件发送到客户端
（c） 将代理预编译为dll（在我这边）并将其发送到客户端
（d） ？？？
?

对这种情况下的最佳实践有何建议，有何利弊

提前感谢，

---

Igor

为什么出于安全原因不需要公开可用的WSDL

我可能愿意承认，发布API（这基本上就是您使用WSDL所做的）会让您比没有发布API时更容易受到攻击，但如果认为隐藏WSDL构成任何类型的安全性，那就错了。具有讽刺意味的是，这被称为默默无闻的安全，任何有决心的攻击者都会破坏它

web服务本身应该是安全的。WCF提供了许多安全特性，但这与您的问题是垂直的

我更喜欢发布WSDL。如果您不想这样做，或者如果有一个适当的策略说您不能这样做，那么将WSDL发送给客户团队，以便他们可以按照自己的意愿使用它

---

预编译代理只会在客户机团队上强制执行您的编码约定，他们可能不理解这一点——例如，我通常更喜欢使用/I开关生成代理，该开关使生成的类成为内部类。我还希望能够指定.NET名称空间，以便它们适合我的其余代码。如果我有一个预编译的程序集，这是不可能的（无论如何我都可以使用它，但这会让我很恼火）。

如果您不想实际发布WSDL并使其可以在线调用客户端，那么我更喜欢“向我发送WSDL和XSD”方法

这样，您仍然可以让调用您的客户机以他们认为合适的方式创建代理的能力和灵活性

<>我只考虑在一个程序集中使用预编译的代理，如果调用方不能或不愿意自己创建代理，并且只有当他们要求我以汇编的形式提供代码时，

---

Marc

按照优先顺序，我倾向于：

让服务公开WSDL（启用安全性）

向服务使用者发送WSDL文件

我本来打算将选项3列为发送代理DLL，但转念一想，我甚至不会将其列为选项。在我看来，给你的客户发送一个代理DLL会打开一个我不想处理的蠕虫的大罐子

主要问题是，您最终不得不支持部署在客户端站点的可执行代码。代理代码可以由svcutil生成，但是如果调用服务时出现某种问题，我可以看到客户机正在呼叫您寻求支持，并告诉您代理无法工作。现在，他们的说法可能不正确，但你很难证明，因为你不知道他们在做什么。e、 g

• 也许他们没有安装代理DLL
• 也许有许可问题
• 也许他们不知道自己在做什么（是的，我知道这永远不会发生）
• 也许他们的.NET升级影响了你的代理
• 在向他们发送新代理时，您甚至可能会遇到一些版本控制难题

---

如果您的客户不是那么精明，而不是试图通过创建代理DLL来帮助他们，那么花一些时间和精力来帮助他们正确配置和使用您的服务可能是一种更好的方法？

谢谢，马克，很好。您完全正确，WSDLGen阻止并不是唯一的安全措施。我更关心的是，客户端无法使用WSDL生成完整的代理。我试图模拟客户机环境，从WSDL链接生成代理到我们的WCF服务，我看到vs2005删除了消息契约对象（需要进一步挖掘）。这就是为什么我考虑使用一个预编译的代理来简化我们和他们的生活，但是正如您所指出的，这对客户机来说可能一点也不“容易”…它不应该删除消息契约对象，但它们可能没有您期望的名称。只需确保您的WCF服务正在使用basicHttpBinding。