Как синхронизировать ресурсы пересмотра и версии SVN файлов EXE/DLL?

Возможно, вы захотите изучить Subversion Properties и Subversion Keywords . Они не решают проблему с ресурсами, так как всегда включают этот проклятый $ 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 , который определяет пользовательский инструмент, который обрабатывает это.

Эта структура дала нам большую гибкость и отслеживаемость во всем процессе штамповки версий. Он превратился из простого куска в пакетном файле в это многоуровневое чудовище, но он работал очень хорошо для нас в течение последних нескольких лет.

Мне трудно поверить, что никто не нашел лучшего способа сделать это все же. Опять же, я не исследовал это в течение ряда лет. Я бы предположил, что вы можете добавить пользовательский файл .rules , который определяет пользовательский инструмент, который обрабатывает это.

Эта структура дала нам большую гибкость и отслеживаемость во всем процессе штамповки версий. Он превратился из простого куска в пакетном файле в это многоуровневое чудовище, но он работал очень хорошо для нас в течение последних нескольких лет.

Мне трудно поверить, что никто не нашел лучшего способа сделать это все же. Опять же, я не исследовал это в течение ряда лет. Я бы предположил, что вы можете добавить пользовательский файл .rules , который определяет пользовательский инструмент, который обрабатывает это.

Я исследовал это в течение ряда лет. Я бы предположил, что вы можете добавить пользовательский файл .rules , который определяет пользовательский инструмент, который обрабатывает это.

Я исследовал это в течение ряда лет. Я бы предположил, что вы можете добавить пользовательский файл .rules , который определяет пользовательский инструмент, который обрабатывает это.

Это отличная помощь, спасибо. Я улучшил это для Visual Studio 2008, если это кому-то поможет.

1 / Создал папку / Build в каждом проекте

2 / Скопировал AssemblyInfo.cs в папку Build как AssemblyInfo.cs.txt, установите для действия сборки значение «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 находится в конфликте. Кажется очевидным. Я исключил его из SVN, используя VisualSVN, чтобы решить эту проблему.

Кажется очевидным. Я исключил его из SVN, используя VisualSVN, чтобы решить эту проблему.

Кажется очевидным. Я исключил его из SVN, используя VisualSVN, чтобы решить эту проблему.