如何同步SVN修订版和EXE/DLL文件的版本资源?

发布于 2024-07-18 04:23:03 字数 187 浏览 5 评论 0原文

假设我有一些构建 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

何处潇湘 2024-07-25 04:23:04

这是很大的帮助,谢谢。 如果对任何人有帮助的话,我已经针对 Visual Studio 2008 对此进行了改进。

1/ 在每个项目中创建一个 /Build 文件夹

2/ 将 AssemblyInfo.cs 作为 AssemblyInfo.cs.txt 复制到 Build 文件夹,将 Build Action 设置为“None”

3/ 编辑 AssemblyInfo.cs.txt 以具有如下版本属性:

[assembly: AssemblyVersion("2.0.0.$WCREV$")]
[assembly: AssemblyFileVersion("2.0.0.$WCREV$")]

4/ 在预构建事件中添加了以下内容:

SubWCRev $(SolutionDir) $(ProjectDir)\Build\AssemblyInfo.cs.txt $(ProjectDir)\Properties\AssemblyInfo.cs

每次编译时都会起作用。

我正在将 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:

[assembly: AssemblyVersion("2.0.0.$WCREV$")]
[assembly: AssemblyFileVersion("2.0.0.$WCREV$")]

4/ Added the following to the Prebuild events:

SubWCRev $(SolutionDir) $(ProjectDir)\Build\AssemblyInfo.cs.txt $(ProjectDir)\Properties\AssemblyInfo.cs

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.

错々过的事 2024-07-25 04:23:03

如果您安装了 TortoiseSVN,那么就会安装一个程序,SubWCRev

如果在您的文件中具有以下值:

$WCREV$

那么如果您执行如下操作,它将被替换为最高提交的修订版号:

SubWCRev .\ yourfile.txt.template yourfile.txt

这将从 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:

$WCREV$

Then it'll be replaced with the highest committed revision number if you execute something like this:

SubWCRev .\ yourfile.txt.template yourfile.txt

This will copy from yourfile.txt.template, do the substitutions, and write to yourfile.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.

孤檠 2024-07-25 04:23:03

Program.X 的答案效果很好。 不过,我想补充一点,如果您在提交更改之前构建可执行文件,则修订版将比运行代码的实际修订版号小 1。 为了缓解这种情况,您可以将版本设置为

"2.0.$WCREV$.$WCMODS?1:0$"

如果有任何本地修改,则在末尾添加 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

"2.0.$WCREV$.$WCMODS?1:0$"

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.

不顾 2024-07-25 04:23:03

您可能需要查看 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 的输出中提取当前修订版本。

SET rootdir=%1
SET svnrev=0
PUSHD "%rootdir%"
FOR /F "tokens=1-4 delims=: " %%I IN ('svn info') DO (
    IF /I {%%I}=={rev} SET svnrev=%%L
)
(ECHO./*
 ECHO. * version-stamp.h - repository version information
 ECHO. */
 ECHO.#ifndef VERSION_STAMP_H
 ECHO.#define VERSION_STAMP_H
 ECHO.#define REPOSITORY_VERSION %svnrev%
 ECHO.#endif) > include\version-stamp.h
POPD

然后,我们创建了一个名为 component-info.h 的组件特定版本标记标头,如下所示:

#ifndef component_info_h
#define component_info_h
#include "product-info.h"
#include "version-stamp.h"

#define VERS_MAJOR 1
#define VERS_MINOR 2
#define VERS_PATCH 3
#define VERS_BUILD REPOSITORY_VERSION

#define MY_COMPONENT_NAME "TPS Report Generator"    
#define MY_VERSION_NUMBER VERS_MAJOR,VERS_MINOR,VERS_PATCH,VERS_BUILD
#define MY_VERSION_STRING VERSION_STRING(VERS_MAJOR,VERS_MINOR,VERS_PATCH,VERS_BUILD)

#endif

最后,我们有一个产品线版本文件,它定义了名为 product-info 的产品信息。 h

#ifndef product_info_h
#define product_info_h

#define PROD_VERS_MAJOR 0
#define PROD_VERS_MINOR 1
#define PROD_VERS_PATCH 0
#define PROD_VERS_BUILD 0

#define VSTR1(s) #s
#define VSTR(s) VSTR1(s)
#define VERSION_STRING(a,b,c,d) VSTR(a) "." VSTR(b) "." VSTR(c) "." VSTR(d) "\0"

#define MY_COMPANY_NAME         "IniTech\0"
#define MY_COPYRIGHT            "Copyright ©2009 " MY_COMPANY_NAME
#define MY_PRODUCT_NAME         "\0"
#define MY_PRODUCT_VERSION_NUM  PROD_VERS_MAJOR,PROD_VERS_MINOR,PROD_VERS_PATCH,PROD_VERS_BUILD
#define MY_PRODUCT_VERSION_STR  VERSION_STRING(PROD_VERS_MAJOR,PROD_VERS_MINOR,PROD_VERS_PATCH,PROD_VERS_BUILD)
#endif

那么您的资源文件包含 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.

SET rootdir=%1
SET svnrev=0
PUSHD "%rootdir%"
FOR /F "tokens=1-4 delims=: " %%I IN ('svn info') DO (
    IF /I {%%I}=={rev} SET svnrev=%%L
)
(ECHO./*
 ECHO. * version-stamp.h - repository version information
 ECHO. */
 ECHO.#ifndef VERSION_STAMP_H
 ECHO.#define VERSION_STAMP_H
 ECHO.#define REPOSITORY_VERSION %svnrev%
 ECHO.#endif) > include\version-stamp.h
POPD

Then we created a component specific version stamping header named component-info.h that looked something like:

#ifndef component_info_h
#define component_info_h
#include "product-info.h"
#include "version-stamp.h"

#define VERS_MAJOR 1
#define VERS_MINOR 2
#define VERS_PATCH 3
#define VERS_BUILD REPOSITORY_VERSION

#define MY_COMPONENT_NAME "TPS Report Generator"    
#define MY_VERSION_NUMBER VERS_MAJOR,VERS_MINOR,VERS_PATCH,VERS_BUILD
#define MY_VERSION_STRING VERSION_STRING(VERS_MAJOR,VERS_MINOR,VERS_PATCH,VERS_BUILD)

#endif

Finally, we had a product-line version file that defined the product information named product-info.h:

#ifndef product_info_h
#define product_info_h

#define PROD_VERS_MAJOR 0
#define PROD_VERS_MINOR 1
#define PROD_VERS_PATCH 0
#define PROD_VERS_BUILD 0

#define VSTR1(s) #s
#define VSTR(s) VSTR1(s)
#define VERSION_STRING(a,b,c,d) VSTR(a) "." VSTR(b) "." VSTR(c) "." VSTR(d) "\0"

#define MY_COMPANY_NAME         "IniTech\0"
#define MY_COPYRIGHT            "Copyright ©2009 " MY_COMPANY_NAME
#define MY_PRODUCT_NAME         "\0"
#define MY_PRODUCT_VERSION_NUM  PROD_VERS_MAJOR,PROD_VERS_MINOR,PROD_VERS_PATCH,PROD_VERS_BUILD
#define MY_PRODUCT_VERSION_STR  VERSION_STRING(PROD_VERS_MAJOR,PROD_VERS_MINOR,PROD_VERS_PATCH,PROD_VERS_BUILD)
#endif

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文