¿Cómo sincronizar la revisión de SVN y los resources de versión de los files EXE / DLL?

Digamos que tengo algún proyecto de C ++ que construye un file exe o dll. El proyecto se registra en un repository SVN. Quiero sincronizar automáticamente la revisión desde SVN con el recurso de versión embedded en mi file exe / dll, es decir, la versión debería ser algo como $ major. $ Minor . $ Svn_revision .
¿Alguna idea sobre cómo lograr esto? ¿Hay alguna solución list para usar disponible?

Si tiene instalado TortoiseSVN, entonces hay un progtwig instalado con él, SubWCRev .

Si, en su file, tiene este valor:

 $WCREV$ 

Luego se replaceá con el número de revisión más alto comprometido si ejecuta algo como esto:

 SubWCRev .\ yourfile.txt.template yourfile.txt 

Esto copyrá desde su yourfile.txt.template , realizará las sustituciones y escribirá en yourfile.txt .

Tenga en count que hay muchas otras macros que puede usar, si ejecuta SubWCRev sin arguments, las mostrará todas en la console.

Esto es de gran ayuda, gracias. Lo he refinado para Visual Studio 2008 si ayuda a alguien.

1 / Creé una carpeta / Build dentro de cada proyecto

2 / Copié AssemblyInfo.cs a la carpeta Build como AssemblyInfo.cs.txt, establezca Build Action en "None"

3 / Editó AssemblyInfo.cs.txt para tener attributes de versión como a continuación:

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

4 / Agregué lo siguiente a los events Prebuild:

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

Esto funciona cada vez que comstacks.

Estoy usando VisualSVN / TortoiseSVN y VisualSVN Server con Visual Studio 2008.

ACTUALIZAR:

Mi colega acaba de actualizar su copy de trabajo y AssemblyInfo.cs está en conflicto. Parece obvio. Lo he excluido de SVN usando VisualSVN para resolver esto.

La respuesta de Program.X funciona de maravilla. Me gustaría agregar, sin embargo, que si construyes tu ejecutable antes de comprometer tus cambios, la revisión será uno less que el número de revisión real del código en ejecución. Para mitigar esto, puede configurar las versiones para

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

Eso pondrá un 1 en el extremo si hay modificaciones locales, y 0 si no. Entonces, si miras más tarde tu ejecutable y ves 2.0.54.1, sabes que probablemente sea la revisión 55.

Es posible que desee examinar las properties de Subversion y las palabras key de Subversion . No resuelven el problema de los resources ya que siempre incluyen esa maldita $KeywordName: ...$ parte. Las properties personalizadas proporcionan un buen método para hacer que los metadatos estén disponibles en los files por lotes y lo que no.

De todos modos, busqué una solución al problema de los resources hace unos años y no encontré ninguno. Entonces, creamos nuestra propia solución local. Cambiamos nuestro file RC para include un file de encabezado que se generó durante el process de compilation. El RC dependía del encabezado y el encabezado tenía una regla de compilation personalizada que invocaba un file por lotes para generar el encabezado. El siguiente fragment extraerá la revisión actual del resultado de la svn info de 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 

Luego creamos un encabezado de estampado de la versión específica del componente llamado component-info.h que se parecía a algo así como:

 #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 

Finalmente, teníamos un file de versión de línea de producto que definía la información del producto llamada 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 

Luego, su file de resources incluye component-info.h y usa varias definiciones en los lugares apropiados (por ejemplo, FILEVERSION MY_VERSION_NUMBER ). Esta estructura nos dio mucha flexibilidad y trazabilidad en todo el process de estampado de la versión. Pasó de ser un simple trozo en un file por lotes a esta monstruosidad multinivel, pero nos ha funcionado muy bien durante los últimos años.

Me resulta difícil creer que nadie ha encontrado una mejor manera de hacer esto todavía. Por otra parte, no lo he investigado durante varios años. Supongo que podría agregar un file .rules personalizado que defina una herramienta personalizada que maneje esto.