Teambuild / MSBuild 和冲压 QA 批准的版本
我们有一个使用 tfs/teambuild 和 msbuild 的软件自动化构建和 QA 流程，并且我们希望能够了解（出于审计目的）组件是否已经完成该流程。
例如，如果一个库安装在用户的计算机上，我希望能够以某种方式检查它以判断它是否已完成构建。特别是，我希望能够将其与直接在开发人员计算机上构建然后手动安装的组件区分开来。
最好的方法是什么？作为构建过程一部分的代码签名似乎最接近这些要求，但想必这不会涵盖可能使用的任何第三方库？我还阅读了有关 ILMerge 工具将所有程序集合并为一个程序集的信息，但我不知道是否可以对它们进行签名？
我确信我们不是第一批有此要求的人，因此请四处寻找可能做过此类事情的其他人的任何想法或提示，
谢谢！
We have an automated build and QA process for our software, using tfs/teambuild and msbuild, and we want to be able to know (for audit purposes) whether a component has gone through that process or not.
For example, if a library is installed on a user's machine, I'd like to be able to inspect it in some way to tell that it went through the build. In particular, I want to be able to distinguish it from components built directly on a developer's machine, and then manually installed.
What is the best way to do this? Code signing as part of the build process seems closest to these requirements, but presumably this would not cover any 3rd-party libraries that might be used? I also read about the ILMerge tool to merge all assemblies into one, but then I don't know enough to work out whether they can then be signed or not?
I'm sure we're not the first people to have the requirement, so casting around for any ideas or hints from others who might have done such a thing
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我们的开发人员构建设置为将版本保留为“0.0.0.0”，但我们的构建服务器根据预先配置的版本和自动生成的构建字符串来标记构建。 “1.0.3.xxx”。您的构建服务器不允许这样做？
Our developer builds are set to keep the versions at "0.0.0.0", but our build server marks the build based on a pre-configured version and automagically generated build string. "1.0.3.xxx". Your build server doesn't allow for this?
您的构建过程应该更新每个项目的 assemblyinfo.cs 文件（或全局链接的等效文件），您可以使用 TFS 变更集编号来执行此操作，因此就像上一张海报所示，您最终会得到每个 dll 1.0 的属性。 changeset.buildno 或类似的东西。您可以在 msbuild 中轻松完成此操作。
您可以将源代码管理中每个程序集信息文件的值设置为明显的值，例如 0 或 999。
不过，您的很多要求也与流程和培训有关。
如果您使用安装程序或 zip 来打包可交付成果，那么您还可以在构建过程中使用构建号来标记它们。
但是，如果您有变更集，您就拥有从 dll 到代码的链接，因此可追踪，再加上每个 csproj 中定义的第三方 dll 引用的链接。
Your build process should be updating each of your projects assemblyinfo.cs files (or a global linked equivalent), you can do this with the TFS changeset number, so like the previous poster indicated you end up with the property on each dll of 1.0.changeset.buildno or something similar. You can do this easily in msbuild.
You could have the values of each assembly info file set in source control to be something obvious like 0 or 999.
A lot of what your asking is about process and training as well though.
If your using installers or zips to package your deliverables then you can also label them with the build number as part of your build process.
But if you have changeset you have the link from dll to code, so traceable, coupled with links to third party dll references as defined in each csproj.