如何同步SVN修订版和EXE/DLL文件的版本资源?
假设我有一些构建 exe 或 dll 文件的 C++ 项目。 该项目已签入 SVN 存储库。 我想自动将 SVN 的修订版本与我的 exe/dll 文件中嵌入的版本资源同步,即版本应该类似于 $major.$minor.$svn_revision。
关于如何实现这一目标有什么想法吗? 有可用的现成解决方案吗?
Say I have some C++ project which builds an exe or dll file. The project is checked into a SVN repository. I want to automatically synchronize the revision from SVN with the version resource embedded in my exe/dll file, i.e. the version should be something like $major.$minor.$svn_revision.
Any ideas on how to achieve this? Are there any out-of-the-box solutions available?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
这是很大的帮助,谢谢。 如果对任何人有帮助的话,我已经针对 Visual Studio 2008 对此进行了改进。
1/ 在每个项目中创建一个 /Build 文件夹
2/ 将 AssemblyInfo.cs 作为 AssemblyInfo.cs.txt 复制到 Build 文件夹,将 Build Action 设置为“None”
3/ 编辑 AssemblyInfo.cs.txt 以具有如下版本属性:
4/ 在预构建事件中添加了以下内容:
每次编译时都会起作用。
我正在将 VisualSVN/TortoiseSVN 和 VisualSVN Server 与 Visual Studio 2008 一起使用。
更新:
我的同事刚刚更新了他的工作副本,并且 AssemblyInfo.cs 存在冲突。 看起来很明显。 我已使用 VisualSVN 将其从 SVN 中排除来解决此问题。
This is great help, thanks. I've refined this for Visual Studio 2008 if it's of any help to anyone.
1/ Created a /Build folder within each project
2/ Copied AssemblyInfo.cs to the Build folder as AssemblyInfo.cs.txt, set the Build Action to "None"
3/ Edited the AssemblyInfo.cs.txt to have version attributes as below:
4/ Added the following to the Prebuild events:
This works everytime you compile.
I am using VisualSVN/TortoiseSVN and VisualSVN Server with Visual Studio 2008.
UPDATE:
My colleague has just updated his working copy and AssemblyInfo.cs is conflicted. Seems obvious. I have excluded it from SVN using VisualSVN to resolve this.
如果您安装了 TortoiseSVN,那么就会安装一个程序,
SubWCRev
。如果在您的文件中具有以下值:
那么如果您执行如下操作,它将被替换为最高提交的修订版号:
这将从
yourfile.txt.template
复制,执行替换,然后写入yourfile.txt
。请注意,您还可以使用许多其他宏,如果您执行不带任何参数的
SubWCRev
,它会在控制台上列出它们。If you have TortoiseSVN installed, then there is a program installed with it,
SubWCRev
.If, in your file, you have this value:
Then it'll be replaced with the highest committed revision number if you execute something like this:
This will copy from
yourfile.txt.template
, do the substitutions, and write toyourfile.txt
.Note that there's a lot of other macros you can use as well, if you execute
SubWCRev
without any arguments, it'll list them all on the console.Program.X 的答案效果很好。 不过,我想补充一点,如果您在提交更改之前构建可执行文件,则修订版将比运行代码的实际修订版号小 1。 为了缓解这种情况,您可以将版本设置为
如果有任何本地修改,则在末尾添加 1,如果没有,则在末尾添加 0。 因此,如果您稍后查看可执行文件并看到 2.0.54.1,您就知道它实际上可能是修订版 55。
The answer by Program.X works great. I'd like to add, though, that if you build your executable before committing your changes, the revision will be one less than the actual revision number of the running code. To mitigate this, you can set the versions to
That will put a 1 on the end if there are any local modifications, and 0 if not. So if you look at your executable later and see 2.0.54.1, you know it's probably actually revision 55.
您可能需要查看 Subversion 属性 和 < a href="http://svnbook.red-bean.com/en/1.5/svn.advanced.props.special.keywords.html" rel="nofollow noreferrer">Subversion 关键字。 他们没有解决资源问题,因为他们总是包含该死的
$KeywordName: ...$
部分。 自定义属性确实提供了一种很好的方法来使元数据在批处理文件中可用,等等。
不管怎样,几年前我就在寻找解决资源问题的方法,但没有找到。 因此,我们创建了自己的本土解决方案。 我们更改了 RC 文件以包含在构建过程中生成的头文件。 RC 依赖于标头,并且标头具有调用批处理文件来生成标头的自定义构建规则。 以下代码片段将从 svn info 的输出中提取当前修订版本。
然后,我们创建了一个名为
component-info.h
的组件特定版本标记标头,如下所示:最后,我们有一个产品线版本文件,它定义了名为
product-info 的产品信息。 h
:那么您的资源文件包含
component-info.h
并在适当的位置使用各种定义(例如,FILEVERSION MY_VERSION_NUMBER
)。 这种结构给我们在整个版本冲压过程中提供了很大的灵活性和可追溯性。 它从批处理文件中的一个简单块成长为这个多层次的怪物,但在过去几年中它对我们来说非常有效。我很难相信还没有人找到更好的方法来做到这一点。 话又说回来,我已经很多年没有调查过它了。 我假设您可以添加一个自定义
.rules
文件来定义处理此问题的自定义工具。You might want to look into Subversion Properties and Subversion Keywords. They don't solve the resource problem since they always include that damned
$KeywordName: ...$
part. Custom properties do provide a nice method for making metadata available in batch files and what not.
Anyway, I looked for a solution to the resource problem a few years ago and didn't find one. So, we created our own home-grown solution. We changed our RC file to include a header file that was generated during the build process. The RC was dependent on the header and the header had a custom build rule that invoked a batch file to generate the header. The following snippet will extract the current revision from the output of
svn info
.Then we created a component specific version stamping header named
component-info.h
that looked something like:Finally, we had a product-line version file that defined the product information named
product-info.h
:Then your resource file includes
component-info.h
and uses the various defines in the appropriate places (e.g.,FILEVERSION MY_VERSION_NUMBER
). This structure gave us a lot of flexibility and traceability in the whole version stamping process. It grew from a simple chunk in a batch file into this multi-leveled monstrosity but it has worked very well for us for the last few years.I find it hard to believe that no one has found a better way to do this yet. Then again, I haven't investigated it for a number of years. I would assume that you could add a custom
.rules
file that defines a custom tool that handles this.