10

我正在构建一个 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能够发展，这就是为什么我从一开始就将它的功能与系统的其他部分分离。在那个演变过程中，它可能会添加更多它将调用的 Web 服务，从而排除手动复制粘贴方法来克服这个问题。

我研究了几种可能的方法来解决这个问题：

  1. 手动将端点和绑定从mydell app.config 复制到目标 EXE 或 web .config 文件。
    耦合模块，不灵活
  2. 使用 configSource（参见此处） 在目标 .config 中包含来自mydll app.config 的端点和绑定。还要增加模块之间的耦合
  3. 以编程方式加载mydll app.config，读取端点和绑定，并实例化 Binding 和 EndpointAddress。
  4. 使用不同的工具为myservice创建本地前端

我不确定该走哪条路。选项 3 听起来很有希望，但事实证明它需要做很多工作并且可能会引入一些错误，所以它值得怀疑。除了规范的 svcutil.exe 之外，我也不熟悉任何工具。

请给出上述替代方案的利弊，提供实施其中任何一个的提示，或提出其他方法。

谢谢，
阿萨夫

4

4 回答 4

4

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

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

于 2010-02-12T08:54:54.983 回答
2

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

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

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

于 2010-04-22T14:21:22.933 回答
0

我也将我的开源 Web 服务框架编译为单个 dll。尽管采用了完全不同的方法，但我为 JSON 和 XML 端点（以及 SOAP 端点的通用 WCF 配置）创建了可以处理每个请求的通用 IHttpHandler。因此，我的配置是一个简单的单行程序，用于将端点映射到我的处理程序的所有Web 服务，该处理程序与应用程序主机 .config 文件（即 ASP.NET Web.config 或控制台 App.config）一起驻留在其应有的位置。

于 2010-02-12T08:59:52.100 回答
0

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

3 和 4 选项的工作量更大。

于 2010-02-12T08:48:45.540 回答