【问题标题】:Version in .NET DLL not reflecting Build or Revision.NET DLL 中的版本不反映 Build 或 Revision
【发布时间】:2018-03-26 00:11:12
【问题描述】:

在 Visual Studio 2012 中使用 C# ...

  • 我在调试或发布模式下构建我的程序集。
  • 我右键单击bin/debugbin/release文件夹中新创建的DLL的属性并选择“属性 ”。
  • 在“详细信息”选项卡上,我查看文件和产品版本属性并看到以下内容...

    文件版本 1.0.0.0

    产品版本 1.0.*

AssemblyInfo.cs 定义了这样的版本...

[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion("1.0.*")]

当我查看 DLL 属性时,我期待...

File Version    1.0.3.19514
Product Version 1.0.3.19514

是否有某些原因导致构建和修订号没有被自动设置,因为世界上所有的文档似乎都表明它们应该这样做?

我毫不怀疑这是我的脑残。 :|

谢谢

【问题讨论】:

  • “在我看到的详细信息选项卡上”1.0.3.19514,“我期待看到”1.0.3.19514。那有什么问题呢?
  • 我错过了什么吗?看来你所期待的和你读到的一样。
  • 啊!!我的坏...错字> 我会更新 OP。这似乎是我的一天的方式:|

标签: c# .net visual-studio visual-studio-2012


【解决方案1】:

如果您在 assemblyinfo.cs 文件中使用星号代替 Build Number,那么您就是在告诉 Visual Studio 应用其规则来计算 Build Number修订号。在编译时 VS 不会将星号更改为存储在程序集中的实际值,因此在下一次编译时它可以重复该过程。

VS 中当前的版本控制规则在 MSDN 上的AssemblyVersionAttribute 页面中进行了解释

很快,他们会说

默认内部版本号每天递增。默认修订号 是自当地时间午夜以来的秒数(不带 考虑夏令时的时区调整),划分 2.

【讨论】:

  • 问题是星号包含在产品版本中,并且在文件版本中始终被替换为“0”。
猜你喜欢
  • 2012-11-14
  • 2010-12-04
  • 1970-01-01
  • 1970-01-01
  • 2011-03-28
  • 1970-01-01
  • 2022-08-24
  • 1970-01-01
  • 2015-08-28
相关资源
最近更新 更多