版本控制：svcmap、disco、xsd、wsdl、svcinfo 和数据源文件

Posted 2023-02-26

【中文标题】版本控制：svcmap、disco、xsd、wsdl、svcinfo 和数据源文件

【英文标题】：Version-control: svcmap, disco, xsd, wsdl, svcinfo and datasource files

【发布时间】：2011-01-27 12:50:48

【问题描述】：

我们有一个名为 Foo 的网络服务。

所以有一个 Foo.svc 文件和 Foo.svc.cs 后面的代码。

我们添加了一个 silverlight 项目并希望使用 Foo.svc 服务，因此我们添加了一个服务引用并将其命名为 FooBar 命名空间。

这将创建以下文件：

Reference.cs Reference.svcmap Foo.xsd Foo.disco configuration.svcinfo Foo.wsdl 还有各种 *.datasource 文件。

随着时间的推移，我们更新了 Foo.svc 并添加了更多的 Web 服务（方法和接口），而 FooBar 目录中的文件数量也在增加。

我在这个目录中有 26 个 Foo(nn).xsd 文件 - 其中 nn = 1 到 26。

我的 configuration.svcinfo 是 configuration91.svcinfo。

我的问题是这个？这些文件中的任何一个都需要版本控制吗？每次构建\部署时是否可以全部删除（只要您进行更新服务引用）？

【问题讨论】：

我不会把这个作为答案，因为我不确定。但只有 reference.cs 文件对我来说是最重要的文件。有时 slsvcutil.exe 无法与 vs 一起正常工作，因此当我使用它为 silverlight 生成引用时，只会生成 Reference.cs。

谢谢！我刚刚在 silverlight 论坛上看到了 David 的相同问题。当然是无用的答案。上帝保佑 Stack Overflow！

【参考方案1】：

Reference.svcmap 文件实际上是服务引用的定义。它包含不同的设置以及源链接。 Reference.svcmap 绝对应该是源代码控制的，因为它实际上是项目项意义上的服务引用。

Reference.cs 包含编译您的代码所依据的生成的合同和代理。是否对文件进行源代码控制取决于您。通常，这是项目代码的一部分，应该受源代码控制，但自动生成它有时会导致意外中断签入。

所有其他文件都是生成合约和代理代码时使用的临时文件。它们共同构成了服务公开的元数据的总和，其中包括服务协定 (*.wsdl)、数据协定 (*.xsd) 和配置信息 (*.svcinfo)。

【讨论】：

测试一下我的理解：本地存储的*.xsd文件是临时文件，Reference.svcmap中的SourceUrl对schema定义有什么影响？

svcmap 中的 url 是生成代理时查询元数据的位置。 *.xsd 文件实际上是从服务的元数据端点返回的。

我正在查看实际端点的存储位置，看起来像是 MetaDataSource 标记的 Address 属性中 Reference.svcmap 中的服务引用。对于 Web 引用，即在 proj 文件中的 WebReferenceUrl 标记中。

实际端点是可配置的，您始终可以使用具有任何基地址的客户端，这在代码和配置中都是可覆盖的。 svcmap 中的 url 通常指向开发/本地服务实例。举例说明一下，您还可以直接从解决方案中的另一个项目生成客户端，在这种情况下，您在开发时根本不需要端点，因为该工具可以从源中提取元数据。跨度>

【参考方案2】：

那些 xsd 文件只是您在创建或更新服务引用时使用的服务的元数据。您实际上可以删除它们，因为它们只是在生成参考文件时使用。无需对这些文件进行版本控制。

【讨论】：

这些文件有必要吗？或者是否所有内容都包含在 ServiceReferences.config 中？删除所有的.datasource、所有的.diso、所有的.svcinfo，甚至references.cs都可以吗？

@DanielWilliams：Reference.cs 实际上会被编译，理论上您可以手动编辑它以添加或更改行为。它不能被删除，除非您想在每次构建代码时更新服务引用，因为它实际上是完成所有工作的。从某种意义上说，其他一切都只是创造它的一步。