CI 플랫폼 (Hudson)을 통해 C # 어셈블리 버전을 자동으로 늘리려면 어떻게해야합니까?


112

저와 저의 그룹은 어셈블리 버전 번호를 늘리는 것이 끔찍하며 우리는 종종 1.0.0.0 버전으로 어셈블리를 제공합니다. 분명히 이것은 많은 두통을 유발합니다.

CI 플랫폼을 통해 우리의 관행이 훨씬 나아지고 있으며 assemblyinfo.cs파일 내의 값이 자동으로 증가하도록 설정하여 어셈블리의 버전이 해당 어셈블리의 코드 변경으로 자동 업데이트되도록 설정하고 싶습니다 .

이전에 또는 명령 줄 (기억할 수 없음)을 통해 값을 증가시키는 방법을 설정 ( Hudson 을 찾기 전에 msbuild)했지만 Hudson을 사용하면 SVN 저장소를 업데이트하고 ANOTHER 빌드를 트리거합니다. Hudson이 매시간 SVN을 폴링하므로 느린 무한 루프가 발생합니다.

Hudson이 버전 번호를 올리는 것이 나쁜 생각입니까? 그것을 수행하는 다른 방법은 무엇입니까?

이상적으로 솔루션에 대한 내 기준은 다음과 같습니다.

  • 빌드 assemblyinfo.cs전에 빌드 번호를 증가시킵니다.
  • 변경된 어셈블리의 빌드 번호 만 증가시킵니다. Hudson이 빌드 할 때마다 프로젝트 폴더를 지우므로 불가능할 수 있습니다.
  • 변경된 assemblyinfo.cs를 코드 저장소 (현재 VisualSVN )에 커밋합니다.
  • Hudson이 다음에 변경 사항을 검색 할 때 새 빌드를 트리거하지 않습니다.

내 머릿속에서이 작업을 수행하면 배치 파일 / 명령을 통해 대부분의 솔루션을 쉽게 찾을 수 있었지만 내 모든 아이디어는 Hudson이 다음에 스캔 할 때 새 빌드를 트리거하도록 만들었습니다. 나는 나를 위해 모든 것을 해줄 누군가를 찾는 것이 아니라, 올바른 방향으로 나를 가리키고, 허드슨이 특정 SVN 커밋을 무시하도록하는 기술 등을 찾는다.

지금까지 내가 찾은 모든 것은 버전 번호를 자동으로 증가시키는 방법을 설명하는 기사 일 뿐이며 무한 루프로 회전 할 수있는 CI 플랫폼은 고려하지 않습니다.

답변:


63

간단한 대안은 major.minor.*AssemblyInfo 파일 템플릿에 설명 된대로 version 특성을로 설정하여 C # 환경에서 어셈블리 버전을 증가 시키도록하는 것 입니다.

하지만 더 포괄적 인 솔루션을 찾고있을 수 있습니다.

수정 (댓글의 질문에 대한 답변) :

에서 AssemblyInfo.cs:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]

나는 전에 이것을 본 적이 없습니다. 그것이 무엇을하는지에 대해 조금 더 자세히 설명해 주시겠습니까? 하나의 IDE 내에서만 작동합니까 아니면 CI 플랫폼을 사용하는 전체 개발자 팀에서 작동합니까?
Allen Rice

ahhh 이전에 그것이 수용 가능한 솔루션 일 수 있지만 # built는 subversion 등에 저장되지 않는다는 것을 본 적이 있습니다. 파일을 보관하도록 Hudson 설정이 있으며 수용 할 수 있도록 저장됩니다. 그 메커니즘이 어떻게 작동하는지 좀 더 조사해야 할 것입니다. 감사합니다! 당신은 그것이 가치로 무엇을 넣을지 결정하는 방법을 모를 것입니다.
Allen Rice

1
귀하의 질문에 대한 답변은 아래 내 답변을 참조하십시오. 값은 빌드 시간에 따라 결정됩니다.
Kyle Trauberman

와,이게 효과가있을 것 같아요. 우리가 그런 간단한 해결책을 어떻게 간과했는지 잘 모르겠습니다
Allen Rice

도움이 되었으면 좋겠습니다. 쉽고 빠른 방법도 올바른 방법인데 왜 어려운 방법을 사용합니까? :)
Greg D

65

다음은 AssemblyFileVersion 특성을 스탬프 처리하기 위해 수행 한 작업입니다.

AssemblyInfo.cs에서 AssemblyFileVersion을 제거했습니다.

AssemblyFileInfo.cs라는 비어있는 새 파일을 프로젝트에 추가합니다.

Hudson 빌드 머신에 MSBuild 커뮤니티 작업 도구 집합을 설치 하거나 프로젝트에서 NuGet 종속성 으로 설치합니다.

msbuild 파일 인 프로젝트 (csproj) 파일을 편집하고 다음을 추가합니다.

어딘가에 <PropertyGroup>버전을 명시 할 것입니다. 예를 들어 읽도록 변경하십시오.

 <Major>1</Major>
 <Minor>0</Minor>
 <!--Hudson sets BUILD_NUMBER and SVN_REVISION -->
 <Build>$(BUILD_NUMBER)</Build>
 <Revision>$(SVN_REVISION)</Revision>

Hudson은 프로젝트가 hudson을 기반으로 빌드 될 때 표시되는 환경 변수를 제공합니다 (Subversion에서 가져 온다고 가정).

프로젝트 파일 하단에

 <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" Condition="Exists('$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets')" />
  <Target Name="BeforeBuild" Condition="Exists('$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets')">
    <Message Text="Version: $(Major).$(Minor).$(Build).$(Revision)" />
    <AssemblyInfo CodeLanguage="CS" OutputFile="AssemblyFileInfo.cs" AssemblyFileVersion="$(Major).$(Minor).$(Build).$(Revision)" AssemblyConfiguration="$(Configuration)" Condition="$(Revision) != '' " />
  </Target>

이것은 MSBuildCommunityTasks를 사용하여 프로젝트가 빌드되기 전에 AssemblyFileVersion 특성을 포함하도록 AssemblyFileVersion.cs를 생성합니다. 원하는 경우 모든 버전 속성에 대해이 작업을 수행 할 수 있습니다.

결과적으로 허드슨 빌드를 발행 할 때마다 결과 어셈블리는 1.0.HUDSON_BUILD_NR.SVN_REVISION (예 : 1.0.6.2632)의 AssemblyFileVersion을 얻습니다. 즉, 허드슨의 6 번째 빌드 번호는 Subversion 개정 2632에서 가져온 것입니다.


1
따라서 이것을 업데이트하기 위해 :이 메서드는 C #에서 작동합니다. 나는 그것을 얼마 동안 사용하고 있습니다. 그러나 C ++ 어셈블리 (예 : C ++ / CLI)는 여전히 문제입니다. 내가 알 수있는 한 AssemblyInfo 작업은 유효한 C ++를 생성하지 않습니다. 또한이 방법은 다른 개발자가 무슨 일이 일어나고 있는지 이해하는 것이 약간 불투명하다는 점에서 약간의 단점이 있다고 생각합니다.
안타깝게도

@CJBrew AssemblyInfo에 대한 C ++ 코드를 생성하는 작은 .bat 파일을 만들고 msbuild가 해당 scipt를 시작하도록 할 수 있습니다. 속성으로 푸시하는 것이 무엇을 의미하는지 잘 모르겠습니다. 원하는 속성에 버전 문자열을 넣을 수 있습니다. 여기에서 사용한 메이저 / 마이너 / 빌드 / 개정을 사용할 필요가 없습니다.
아니오

이 경로를 사용하여 얻은 것이 있습니까? AssemblyFileVersion을 주석으로 처리하고 [assembly : AssemblyVersion ( "1.0. *")]과 자동으로 일치하도록 설정하는 것입니까?
cchamberlain

@ColeChamberlain Hudson이 아닌 자신의 PC에서 Visual Studio에서 빌드하면 자동으로 증가합니다. 버전 번호, 특정 빌드 및 소스 코드 개정과는 관련이 없습니다.
nos

42

다음은 새 프로젝트를 추가 할 때 약간의 사전 작업이 필요하지만 프로세스를 매우 쉽게 처리하는 우아한 솔루션입니다.

아이디어는 각 프로젝트가 어셈블리 버전 정보 만 포함하는 솔루션 파일에 연결된다는 것입니다. 따라서 빌드 프로세스는 단일 파일 만 업데이트하면되고 모든 어셈블리 버전은 컴파일시 하나의 파일에서 가져옵니다.

단계 :

  1. 솔루션 파일 * .cs 파일에 클래스를 추가하십시오. 이름은 min SharedAssemblyProperties.cs입니다.
  2. 새 파일에서 모든 cs 정보를 제거하십시오.
  3. AssemblyInfo 파일에서 어셈블리 정보를 잘라냅니다. [assembly : AssemblyVersion ( "1.0.0.0")] [assembly : AssemblyFileVersion ( "1.0.0.0")]
  4. "using System.Reflection;"문을 추가하십시오. 파일에 데이터를 붙여 넣은 다음 새 cs 파일 (예 : SharedAssemblyProperties.cs)에 데이터를 붙여 넣습니다.
  5. 프로젝트에 기존 항목을 추가하십시오 (파일을 추가하기 전에 계속 읽으십시오).
  6. 파일을 선택하고 추가를 클릭하기 전에 추가 버튼 옆의 드롭 다운을 클릭하고 "링크로 추가"를 선택합니다.
  7. 솔루션의 모든 기존 프로젝트와 새 프로젝트에 대해 5 단계와 6 단계를 반복합니다.

파일을 링크로 추가하면 프로젝트 파일에 데이터가 저장되고 컴파일시이 파일에서 어셈블리 버전 정보를 가져옵니다.

소스 제어에서 단순히 SharedAssemblyProperties.cs 파일을 증가시키는 bat 파일 또는 스크립트 파일을 추가하면 모든 프로젝트가 해당 파일에서 어셈블리 정보를 업데이트합니다.


고마워, 마크. 죽은 링크에 대해 죄송합니다. 커뮤니티 서버가 이동하기 쉽지 않은 것으로 나타났습니다. 나는 ... 그 주제에 대한 도움말을 검색한다
sondlerd

11

Hudson은 특정 경로 및 파일에 대한 변경 사항을 무시하도록 구성하여 새 빌드를 프롬프트하지 않도록 할 수 있습니다.

작업 구성 페이지의 소스 코드 관리 아래 에서 고급 버튼을 클릭 합니다. 에서 제외 된 지역 상자는 경기를 제외 하나 이상의 정규 표현식을 입력합니다.

예를 들어 version.properties 파일의 변경 사항을 무시 하려면 다음을 사용할 수 있습니다.

/MyProject/trunk/version.properties

이것은 C # 이외의 언어에서 작동하며 Subversion 내에 버전 정보를 저장할 수 있습니다.


1
Hudson은 특정 사용자의 커밋을 무시하거나 커밋 메시지에 따라 빌드를 트리거하지 않을 수도 있습니다. 이렇게하면 Hudson의 모든 커밋을 무시할 수 있습니다.
Peter Schuetze

9

.NET이이 작업을 수행합니다. AssemblyInfo.cs 파일에서 어셈블리 버전을 major.minor. * (예 : 1.0. *)로 설정합니다.

프로젝트를 빌드하면 버전이 자동으로 생성됩니다.

빌드 및 개정 번호는 유닉스 시대를 사용하여 날짜를 기반으로 생성됩니다. 빌드는 현재 날짜를 기반으로하고 개정은 자정 이후 초 수를 기반으로합니다.


21
<ring, ring> "안녕하세요. 제품 지원에 대해 어떻게 도와 드릴까요?" <고객> "오류가 있습니다."<support> "알겠습니다. 어떤 버전을 실행 중입니까?" <고객> "버전 1 점 2 개정 8 5 2 5 3 7 4 빌드 7 4 6 3 5 2 9 ..."<지원> "잠시만 요, 그냥 타이핑 ... 음 ... 버전을 반복하세요 번호, 우리는 그 빌드와 개정이 나열되지 않은 것 같습니다 ... "-GRRR!
Jimbo

하하 좋은 댓글. 나도 그 증가 시스템의 팬이 아니에요 : P
여호수아 헤이즈

3
Visual Studio의 자동 증가는 심각하게 짜증납니다.
Kugel 2011 년

8
@Jimbo : 우리 모두가 귀하의 의견이 재미 있다는 데 동의하지만 실제로는 중요하지 않습니다. VS 설치에 대해 말할 때 Visual Studio 2008 SP1 또는 VS2008 9.0.30729.1 SP가 있습니까? 자동 증가 빌드 번호를 사용하는 것은 매우 일반적인 계획이며 릴리스 빌드가 나올 때 주 / 부 버전 번호를 증가시켜 매우 쉽게 "고정"할 수 있습니다.
Marek

빌드 번호가 가장 높은 빌드 번호는 678입니다. 마이너 수정을 위해 0으로 재설정하기 전에 (물론 cruisecontrol, cruisecontrol에서와 같이 hudson보다 재설정하는 것이 더 쉬웠습니다. 방금 들어가서 프로젝트에서 0으로 다시 저장했습니다.) 하지만 허드슨의 다른 모든) 더
딘 힐러

8

1.0. * 기능이 VS2005 또는 VS2008에서 작동하는 것을 실제로 본 적이 없습니다. 값을 증가시키기 위해 VS를 설정하기 위해 수행해야 할 작업이 있습니까?

AssemblyInfo.cs가 1.0. *로 하드 코딩 된 경우 실제 빌드 / 개정은 어디에 저장됩니까?

1.0. *를 AssemblyInfo에 넣은 후 ProductVersion에 잘못된 값이 있기 때문에 다음 문을 사용할 수 없습니다. VS에서 할당 한 값이 아닌 1.0. *를 사용하고 있습니다.

Version version = new Version(Application.ProductVersion);

한숨-이것은 모두가 물어 보는 것들 중 하나 인 것 같지만 어떻게 든 확실한 대답은 없습니다. 몇 년 전에 수정 번호를 생성하고 빌드 후 프로세스의 일부로 AssemblyInfo에 저장하는 솔루션을 보았습니다. VS2008에는 이런 종류의 춤이 필요하지 않기를 바랐습니다. 어쩌면 VS2010?


10
AssemblyFileVersion을 제거해야합니다. 그 외에는 우리를 위해 굉장한 결과를 얻었습니다.
Allen Rice

1
예, AssemblyFileVersion을 제거하면 버전을 업데이트 할 수 있으며 버전에 더 이상 오류가 발생하지 않습니다. 좋은. 참고 : 두 번의 빌드 작업은 개정을 한 번만 증가 시키지만 다시 빌드하면 개정이 업데이트됩니다. ktrauberman이 말했듯이, 이는 build.revision = date.time처럼 보이며, 데이터가 어셈블리를 제외하고 어디에도 저장되지 않는 이유를 설명합니다. 이제 기본 출력 프로젝트가 업데이트 될 때 새 ProductCode를 생성하기 위해 표준 MSI 설정을 가져와야합니다. 설정은 수정을 허용하지 않고 빌드 만 허용합니다. 업데이트를 수행하기 위해 기존 설치 위에 설치하고 싶습니다. 조사가 필요합니다.
TonyG

5

아래 AssemblyVersion.tt와 같은 환경에서 문제의 어셈블리 특성을 즉석에서 만드는 텍스트 템플릿 을 사용 하여이 작업을 수행 할 수도 있다고 가정 합니다.

<#@ template debug="false" hostspecific="false" language="C#" #>
<#@ output extension=".cs" #>
<#
var build = Environment.GetEnvironmentVariable("BUILD_NUMBER");
build = build == null ? "0" : int.Parse(build).ToString();
var revision = Environment.GetEnvironmentVariable("SVN_REVISION");
revision = revision == null ? "0" : int.Parse(revision).ToString();    
#>
using System.Reflection;
[assembly: AssemblyVersion("1.0.<#=build#>.<#=revision#>")]
[assembly: AssemblyFileVersion("1.0.<#=build#>.<#=revision#>")]

3

MikeS의 답변의 연속으로 VS + Visual Studio Visualization and Modeling SDK가 작동하려면 설치해야하며 프로젝트 파일도 수정해야한다고 추가하고 싶습니다. 또한 언급해야 할 것은 버전 모듈이있는 Windows 2008 R2 서버 상자에서 실행되는 빌드 서버로 Jenkins를 사용합니다. 여기서 BUILD_NUMBER를 얻습니다.

내 텍스트 템플릿 파일 version.tt는 다음과 같습니다.

<#@ template debug="false" hostspecific="false" language="C#" #>
<#@ output extension=".cs" #>
<#
var build = Environment.GetEnvironmentVariable("BUILD_NUMBER");
build = build == null ? "0" : int.Parse(build).ToString();
var revision = Environment.GetEnvironmentVariable("_BuildVersion");
revision = revision == null ? "5.0.0.0" : revision;    
#>
using System.Reflection;
[assembly: AssemblyVersion("<#=revision#>")]
[assembly: AssemblyFileVersion("<#=revision#>")]

속성 그룹에 다음이 있습니다.

<PropertyGroup>
    <TransformOnBuild>true</TransformOnBuild>
    <OverwriteReadOnlyOutputFiles>true</OverwriteReadOnlyOutputFiles>
    <TransformOutOfDateOnly>false</TransformOutOfDateOnly>
</PropertyGroup>

Microsoft.CSharp.targets를 가져온 후이 기능이 있습니다 (VS를 설치 한 위치에 따라 다름).

<Import Project="C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TextTemplating\v10.0\Microsoft.TextTemplating.targets" />

내 빌드 서버에서 다음 스크립트를 사용하여 실제 빌드 전에 텍스트 변환을 실행하여 TFS에서 마지막 변경 집합 번호를 얻습니다.

set _Path="C:\Build_Source\foo"

pushd %_Path% 
"%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\tf.exe" history . /r /noprompt /stopafter:1 /Version:W > bar
FOR /f "tokens=1" %%foo in ('findstr /R "^[0-9][0-9]*" bar') do set _BuildVersion=5.0.%BUILD_NUMBER%.%%foo
del bar
popd

echo %BUILD_NUMBER%
echo %_BuildVersion%
cd C:\Program Files (x86)\Jenkins\jobs\MyJob\workspace\MyProject
MSBuild MyProject.csproj /t:TransformAll 
...
<rest of bld script>

이렇게하면 빌드 및 변경 집합을 추적 할 수 있으므로 마지막 빌드 이후에 아무것도 확인하지 않은 경우 마지막 숫자는 변경되지 않아야하지만 빌드 프로세스를 변경했을 수 있으므로 두 번째 마지막 숫자가 필요합니다. . 물론 빌드 전에 여러 번 체크인하면 마지막 변경 사항 만 버전에 반영됩니다. 나는 당신이 그것을 연결할 수 있다고 생각합니다.

나는 당신이 더 멋진 것을 할 수 있고 tt 템플릿 내에서 직접 TFS를 호출 할 수 있다고 확신하지만 이것은 나를 위해 작동합니다.

그런 다음 런타임에 내 버전을 다음과 같이 가져올 수 있습니다.

Assembly assembly = Assembly.GetExecutingAssembly();
FileVersionInfo fvi = FileVersionInfo.GetVersionInfo(assembly.Location);
return fvi.FileVersion;

1

내 솔루션에는 외부 도구 나 스크립팅 언어를 추가 할 필요가 없습니다. 빌드 머신에서 작동하는 것이 거의 보장됩니다. 이 문제를 여러 부분으로 해결합니다. 먼저 Jenkins BUILD_NUMBER 매개 변수를 환경 변수로 변환하는 BUILD.BAT 파일을 만들었습니다. Jenkins 빌드에 대한 다음 정보를 입력하여 Jenkins의 "Execute Windows batch command"기능을 사용하여 빌드 배치 파일을 실행합니다.

     ./build.bat --build_id %BUILD_ID% -build_number %BUILD_NUMBER%

빌드 환경에서 다음과 같이 시작하는 build.bat 파일이 있습니다.

     rem build.bat
     set BUILD_ID=Unknown
     set BUILD_NUMBER=0
     :parse_command_line
     IF NOT "%1"=="" (
         IF "%1"=="-build_id" (
             SET BUILD_ID=%2
             SHIFT
             )
         IF "%1"=="-build_number" (
             SET BUILD_NUMBER=%2
             SHIFT
         )
         SHIFT
         GOTO :parse_command_line
     )
     REM your build continues with the environmental variables set
     MSBUILD.EXE YourProject.sln

그런 다음 Visual Studio의 솔루션 탐색기 창에서 빌드 할 프로젝트를 마우스 오른쪽 단추로 클릭하고 속성을 선택하고 빌드 이벤트를 선택한 다음 .cs 파일을 자동으로 생성하는 빌드 전 이벤트 명령 줄로 다음 정보를 입력했습니다. 현재 환경 변수 설정에 따른 빌드 번호 정보 포함 :

     set VERSION_FILE=$(ProjectDir)\Properties\VersionInfo.cs
     if !%BUILD_NUMBER%==! goto no_buildnumber_set
     goto buildnumber_set
     :no_buildnumber_set
     set BUILD_NUMBER=0
     :buildnumber_set
     if not exist %VERSION_FILE% goto no_version_file
     del /q %VERSION_FILE%
     :no_version_file
     echo using System.Reflection; >> %VERSION_FILE%
     echo using System.Runtime.CompilerServices; >> %VERSION_FILE%
     echo using System.Runtime.InteropServices; >> %VERSION_FILE%
     echo [assembly: AssemblyVersion("0.0.%BUILD_NUMBER%.1")] >> %VERSION_FILE%
     echo [assembly: AssemblyFileVersion("0.0.%BUILD_NUMBER%.1")] >> %VERSION_FILE%

빌드 취향에 맞게 조정해야 할 수도 있습니다. 주 프로젝트의 Properties 디렉터리에 초기 Version.cs 파일을 생성하기 위해 프로젝트를 수동으로 한 번 빌드합니다. 마지막으로 Version.cs 파일을 해당 프로젝트의 속성 탭 아래에있는 솔루션 탐색기 창으로 끌어 Visual Studio 솔루션에 수동으로 포함합니다. 이후 빌드에서 Visual Studio는 Jenkins 빌드 시간에 해당 .cs 파일을 읽고 올바른 빌드 번호 정보를 가져옵니다.


1

따라서 버전 번호가 다른 어셈블리가있는 여러 프로젝트가 포함 된 하나의 솔루션이있는 프로젝트가 있습니다.

위의 여러 방법을 조사한 후 AssemblyInfo.cs 파일에서 찾기 및 바꾸기를 수행하는 Powershell 스크립트를 실행하는 빌드 단계를 구현했습니다. 나는 여전히 소스 제어에서 1.0. * 버전 번호를 사용하고 Jenkins는 msbuild가 실행되기 전에 수동으로 버전 번호를 업데이트합니다.

dir **/Properties/AssemblyInfo.cs | %{ (cat $_) | %{$_ -replace '^(\s*)\[assembly: AssemblyVersion\("(.*)\.\*"\)', "`$1[assembly: AssemblyVersion(`"`$2.$build`")"} | Out-File $_ -Encoding "UTF8" }
dir **/Properties/AssemblyInfo.cs | %{ (cat $_) | %{$_ -replace '^(\s*)\[assembly: AssemblyFileVersion\("(.*)\.\*"\)', "`$1[assembly: AssemblyFileVersion(`"`$2.$build`")"} | Out-File $_ -Encoding "UTF8" }

-Encoding "UTF8"옵션을 추가했습니다. git이 .cs 파일을 그렇지 않은 경우 바이너리 파일로 취급하기 시작했기 때문입니다. 물론, 실제로 결과를 커밋하지 않았기 때문에 이것은 중요하지 않았습니다. 내가 테스트하는 동안 나왔다.

우리의 CI 환경에는 이미 Jenkins 빌드를 특정 git 커밋과 연결하는 기능이 있으므로 (Stash 플러그인에 감사드립니다!) 버전 번호가 첨부 된 git 커밋이 없어도 걱정하지 않습니다.


0

이것은 더 간단한 메커니즘입니다. MSBuild 단계 이전에 Windows Batch 명령 작업 빌드 단계를 추가하고 FART (단순 찾기 및 바꾸기 프로그램)를 사용하면됩니다.

배치 단계

fart --svn -r AssemblyInfo.cs "[assembly: AssemblyVersion(\"1.0.0.0\")]" "[assembly: AssemblyVersion(\"1.0.%BUILD_NUMBER%.%SVN_REVISION%\")]"
if %ERRORLEVEL%==0 exit /b 1
fart --svn -r AssemblyInfo.cs "[assembly: AssemblyFileVersion(\"1.0.0.0\")]" "[assembly: AssemblyFileVersion(\"1.0.%BUILD_NUMBER%.%SVN_REVISION%\")]"
if %ERRORLEVEL%==0 exit /b 1
exit /b 0

svn 이외의 소스 제어를 사용하는 경우 scm 환경에 적합한 옵션으로 --svn 옵션을 변경하십시오.

방귀 다운로드


0

Prebuild Powershell 스크립트 ( https://gist.github.com/bradjolicoeur/e77c508089aea6614af3 ) 를 사용하여 두 가지 방법을 사용하여 Global.asax에서 성공한 각 빌드를 증가 시키기로 결정했습니다 .

  // We are using debug configuration, so increment our builds.
  if (System.Diagnostics.Debugger.IsAttached)
  {
      string version = System.Reflection.Assembly.GetExecutingAssembly()
                                                       .GetName()
                                                       .Version
                                                       .ToString();

      var psi = new ProcessStartInfo(@"svn", "commit -m \"Version: " + version + "\n \"");
      psi.WorkingDirectory = @"C:\CI\Projects\myproject";
      Process.Start(psi); 
  }

나는 여전히 전체 프로세스가 너무 복잡하다고 생각하며 동일한 결과를 달성하는 더 효율적인 방법을 조사 할 것입니다. 나는 주로 버전을 SVN에 전달한 다음 너무 많은 추가 도구없이 Jenkin에 전달하기 위해 이것을 원했습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.