您如何在源代码控制下管理 VS .designer 文件中的运行时版本更改？答案

【问题标题】：How do you manage Runtime Version changes in VS .designer files under source control?您如何在源代码控制下管理 VS .designer 文件中的运行时版本更改？
【发布时间】：2014-02-07 04:52:29
【问题描述】：

Visual Studio 中的许多自动生成的 .Designer 文件都包含一个样板，如下所示。

'------------------------------------------------------------------------------
' <auto-generated>
'     This code was generated by a tool.
'     Runtime Version:4.0.30319.18052
'
'     Changes to this file may cause incorrect behavior and will be lost if
'     the code is regenerated.
' </auto-generated>
'------------------------------------------------------------------------------

默认情况下，我们总是将这些设计器文件签入源代码管理。事实证明这与Microsoft's recommendation 一致：“自定义工具在设计时而不是在构建时运行，因此需要将依赖文件检入源代码控制”。不幸的是，那里的大多数 SO 问题都询问是否应该签入这些设计器文件 (for example)，而忽略了不断变化的运行时版本的问题以及它对源代码控制的影响。

Dan Brackett 在this question 中谈到了这个问题，只是他的问题是针对将所有开发人员同步到同一版本的解决方案。这似乎是一项令人生畏的任务，特别是正如所引用问题的响应者所指出的那样，承包商会参与其中。有趣的是，Dan 还认为这在 VS 2010 中不再是问题。但是，在 VS 2012 中似乎是一个问题。也许有一个配置值可以将其关闭？

当多个开发人员（每个都有不同的 .Net 版本）使用更新的运行时版本签入这些自动生成的文件时，这是一个挑战。这为他们修复了它，但随后其他开发人员显示过时/更改的文件。

一种选择是允许文件保持过时状态而不签入更改，但这会使开发人员难以信任项目或文件的源代码控制状态。

另一种选择是使用您的源代码控制软件忽略它们，但这些文件确实会合法更改，并且忽略它们可能会丢失重要更新或错过将有效更改签回存储库的风险。

我们还有其他选择吗？

更新：为了进一步澄清，我们不希望开发人员针对不同的 .Net 版本，例如 3.5 和 4.0。我们关心的不是版本的“4.0.30319”部分，而是随着 Windows 和 Visual Studio 的自动更新而发生变化的最后一个维护部分。

【问题讨论】：

这是一个不常见的问题。周围没有多少开发商店让他们的开发人员随意安装更新。拥有一个纳粹 IT 人员是有好处的。
@HansPassant 听到这个消息真是令人惊讶。我从未听说过 IT 人员参与安装的 .Net 版本。我可以想象，buildmaster 会有话要说。无论哪种方式，我关心的不是版本的“2.0.50727”部分，而是随着 Windows 和 Visual Studio 的自动更新而发生变化的最后一个维护部分。我会更新问题以澄清这一点。
当然，这是随着安全和服务版本更新而改变的。通过 Windows 更新分发的那种。 IT 人员使用 WSUS 向客户推送更新。

标签： .net visual-studio version-control

【解决方案1】：

就像老笑话说的那样，“不要这样做！”

处理相同代码的每个人都必须针对相同的 .NET 版本。这是根据每个项目选择的。这绝非偶然 - 您不会得到您的开发人员碰巧运行的任何版本的 .NET。

您没有找到任何关于此的讨论，因为这不是问题。请记住，自 .NET 1.0 以来，这已经不是问题了 - 十多年前了。

【讨论】：

我绝对同意针对不同的 .Net 版本进行开发将是一场灾难，并且不同意该版本的后果确实使它成为必要和“非问题”，正如您所说。但是，对于在 .Net 4.0 等主要版本之后反复进行的维护版本，是否可以这样说？对问题中的任何混淆表示歉意。我已对其进行了更新以澄清。
这不是问题。在项目中设置目标版本，让大家坚持下去。
您是否建议除了锁定要在项目中使用的 .Net 框架的主要/次要版本之外，还应为每个项目专门选择第 3 和第 4 版本数字？这样做与 Visual Studio 只允许您为目标框架选择一个 major.minor 版本（即 3.5、4.0）这一事实不冲突吗？
该项目只能使用一个版本。时期。 Visual Studio 可能只允许您指定major.minor：如果您要在企业环境中操作，则必须控制开发人员工作站。如果您只是不关心正在使用的版本，那么也不要关心评论中的版本号！
或者...维护版本不那么重要，或者至少预计会定期更改而不会破坏主要/次要版本的功能。这种观点将完美地支持目标框架下拉列表中仅列出主要/次要版本的事实。它还支持 IIS 应用程序池设置中缺少第 4 个版本号。在这种情况下，在一堆自动生成的文件的 cmets 中添加第 4 个版本号是不常见的。尤其是当预计这个数字会反复变化时。