在我的工作中,源代码管理中每个项目的程序集版本保持为 1.0.0.0。当构建机器进行新的每日构建时,它具有更新程序集版本的任务,但不会签入更新的 assemblyinfo.cs。所以在我们的开发机器上,我们正在编译的 dll 的汇编版本总是设置为 1.0.0.0。
最好的做法是在源代码管理中保持程序集版本是最新的,还是我们已经在做正确的事情?
每种可能性的优缺点是什么?
谢谢
相关或重复:
AssemblyInfo.cs 是否应该放在版本控制中?
在我的工作中,源代码管理中每个项目的程序集版本保持为 1.0.0.0。当构建机器进行新的每日构建时,它具有更新程序集版本的任务,但不会签入更新的 assemblyinfo.cs。所以在我们的开发机器上,我们正在编译的 dll 的汇编版本总是设置为 1.0.0.0。
最好的做法是在源代码管理中保持程序集版本是最新的,还是我们已经在做正确的事情?
每种可能性的优缺点是什么?
谢谢
相关或重复:
AssemblyInfo.cs 是否应该放在版本控制中?
缺点:
顺便说一句,有一种更简单的方法可以确保所有程序集版本同步:在所有其他程序集引用的顶级程序VersionMask
集中的公共类中定义一个公共 const 字符串“” ,并将VersionInfo
[assembly: AssemblyVersion(VersionInfo.VersionMask)]
在每个 AssemblyInfo.cs 文件中(前提是您使用 C#),对于 VB.NET 它是
<Assembly: AssemblyVersion(VersionInfo.VersionMask)>
这是不正确的,您不应自动更新 [AssemblyVersion]。当 CLR 寻找要加载的程序集的正确版本时,该属性在程序集解析过程中起着非常重要的作用。尽管这仅在程序集存储在 GAC 中时才有区别。最好仅在开发人员在程序集的公共接口中进行重大更改时才应更改它,这将使其在未使用更新的参考程序集重新编译的应用程序中无法使用。
您可以随时更新 [AssemblyFileVersion]。当您查看版本属性选项卡时,这也是资源管理器中可见的版本。现在您也不再关心文件是否被签入。
作为比较,从 .NET 2.0 到 .NET 3.5 SP1 的 .NET 程序集也是如此。所有标准程序集都停留在程序集版本 2.0.0.0,文件版本已更改数千次。然而,这些变化总是兼容的,这是一个非常艰难的行为。
我的方法一直是,你应该能够通过访问源代码控制系统来构建这个东西。因此,如果更新 assemblyinfo.cs 的脚本在源代码管理中,那么没问题。
我想最好将版本存储在 assemblyinfo.cs 中,以便任何人都可以签出并构建正确的版本。在 Dev env 上具有相同的程序集版本。在调试特定版本时也会产生问题。.NET 程序集版本也很重要,因为没有正确版本的 dll,程序集将无法加载,这也有助于您进行调试。