Question

我正在构建一个DLL，我们称之为 mydll.dll ，在其中我有时需要从webservice， myservice 调用方法。 mydll.dll 是使用C＃和.NET 3.5构建的。

从 mydll 使用 myservice 我在Visual Studio 2008中添加了一项服务，这与使用 svcutil.exe大致相同。这样做会创建一个我可以创建的类，并将端点和绑定配置添加到 mydll app.config。

这里的问题是从未加载 mydll app.config。相反，加载的是我使用 mydll 的程序的app.config或web.config。

我希望 mydll 能够进化，这就是为什么我将它的功能从我的系统的其余部分开始解耦。在这个演变过程中，它可能会增加更多的网络服务，它会调用手动复制粘贴方法来克服这个问题。

我已经研究了几种可能的攻击方法：

将 mydell app.config中的端点和绑定手动复制到目标EXE或web .config文件。
模块耦合，不灵活
使用configSource在目标.config中包含来自 mydll app.config的端点和绑定（请参阅here）。 还在模块之间添加耦合
以编程方式加载 mydll app.config，读取端点和绑定，并实例化Binding和EndpointAddress。
使用其他工具为 myservice

我不知道该走哪条路。选项3看起来很有希望，但事实证明它的工作很强大，很可能会引入一些错误，所以它无疑会得到回报。除了规范的svcutil.exe之外，我也不熟悉任何工具。

请为上述替代方案提供优缺点，提供实施其中任何方案的提示，或建议其他方法。

谢谢，
阿萨夫

Answer 1

我更喜欢选项5 - “在代码配置中”，是的是，您失去了更改 - 无需重新编译的好处，但取决于您需要什么。如果您知道永远不会更改端点或者很少更改端点 - 只需在代码中进行配置，您将获得编译时检查作为奖励=）This和this可以提供帮助。

顺便说一句，客户端配置中的配置是常见的情况，如果你有很多这样的客户，这可能会很痛苦，你应该考虑3或5 =）

Answer 2

您可以在使用DLL的应用程序中使用svcutil作为构建后事件。像这样：

svcutil.exe <service_address> /config:$(TargetPath).config /mergeConfig

这会将必要的配置合并到yourapp.exe.config中。如果你在DLL中添加一个新的服务引用，你必须在这里添加另一行，所以它不是完全自动的，但仍然比手动复制配置更简单。

Answer 3

我应该从选项1或2开始（对我来说这个更好）。模块耦合在dll中，因此它们已经耦合。更改配置是微不足道的，但为阅读构建基础设施会让您更多。

3和4选项是一项更多的工作。

Answer 4

我已将open source web services framework编译为单个dll。虽然完全采用了不同的方法，但我为JSON和XML端点（以及SOAP端点的通用WCF配置）创建了通用的IHttpHandler，可以处理每个请求。因此，我的配置是一个简单的单行，用于所有我的Web服务，将端点映射到我的处理程序，该处理程序驻留在应用程序主机.config文件中（即ASP.NET Web.config或Console App.config））它应该是什么意思。

从.NET DLL - app.config问题中使用webservice

4 个答案: