Visual Studio 2017(.NET Core)での自動バージョン管理


112

.NETCoreApp 1.1(Visual Studio 2017)でバージョンを自動インクリメントする方法を見つけるために、数時間の大半を費やしてきました。

AssemblyInfo.csがフォルダーに動的に作成されていることを知っています。 obj/Debug/netcoreapp1.1/

以下の古い方法は受け入れません。 [assembly: System.Reflection.AssemblyFileVersionAttribute("1.0.0.*")]

プロジェクトをパッケージに設定すると、そこにバージョンを設定できますが、これはAssemblyInfo.csファイルのビルドに使用されているようです。

私の質問は、.NET Core(またはそのことについては.NETStandard)プロジェクトでバージョンを制御する方法を誰かが理解していることです。


これでどれだけ進んだかはわかりませんが、ほぼ同じ質問に別の方法で質問したようです(stackoverflow.com/a/43280282/685341)-この質問への回答が承認されると役立つ場合があります。ビルドスクリプトで/p:フラグを渡して、dotnet msbuildバージョン、会社、著作権などを設定できます。
ジェイ

2
情報をありがとう。それだけで追加のオプションが開きます。
Jason H


4
FWIWアセンブリバージョンのワイルドカードはサポートされていません。これらの新しいプロジェクトでは、コンパイラーの「確定的」モードがデフォルトでアクティブになっているためです。自動インクリメントは確定性を損なうため(同じ入力>同じ出力)、そのモードでは許可されません。<Deterministic>False</Deterministic>csprojで設定して使用できます。(または他のMSbuildロジックを使用して<VersionPrefix>/ を計算します<Version>
Martin Ullrich

回答:


23

私はcsproj構成形式を使用してVS2017のNet Coreアプリのバージョンインクリメンターを探していました。

私は、project.json形式で機能するドットネットバンプと呼ばれるプロジェクトを見つけましたが、.csproj形式の解決策を見つけるのに苦労しました。ドットネットバンプの作者は、実際に.csproj形式のソリューションを考え出し、それをMSBumpと呼びます。

GitHubには、次の場所にプロジェクトがあります。

https://github.com/BalassaMarton/MSBump

Nugetでもコードとそのコードを確認できます。NugetでMSBumpを検索してください。


1
MSBumpの最新の2.1.0リリースを使用することをお勧めします。これは、構成の切り替えをより適切にサポートし、次のビルドではなく現在のビルドのバージョンを設定します(以前のバージョンのように)。
マートンバラッサ

以前はビジュアルスタジオが必要でしたが、MSBuildもサポートしています。
ravetroll

2
はい、マルチターゲティングプロジェクトもサポートしています。
マートンバラッサ

4
GitVersioningの使用を検討してください。CI環境での実行に適している場合があります。github.com/AArnott/Nerdbank.GitVersioning
Henrique

1
MSBumpは、何も変更していなくても、ビルドごとにバージョンを増分します。これにより、長期的には多くの問題が発生します。また、バージョンが同期しなくなり、一方のバージョンが他方のバージョンより遅れることがあります。
Konrad

68

<Deterministic>False</Deterministic><PropertyGroup>.csprojのセクション内に追加 

AssemblyVersion *を機能させるための回避策については、「。Net Core#22660の[AssemblyVersion]でのワイルドカードの混乱のエラーメッセージ」を参照してください。

ワイルドカードは、ビルドが確定的でない場合にのみ許可されます。これは、.Net Coreプロジェクトのデフォルトです。<Deterministic>False</Deterministic> csprojに追加  すると、問題が修正されます。

.Net Core開発者がhttp://blog.paranoidcoding.com/2016/04/05/deterministic-builds-in-roslyn.html で説明されている確定的ビルドを有益であると考える理由とコンパイラは確定的である必要があります。同じ入力が同じ出力を生成する# 372

ただし、TeamCity、TFS、またはその他のCI / CDツールを使用している場合は、バージョン番号を制御してインクリメントし、パラメーターとしてビルドに渡すことをお勧めします(他の回答で提案されています)。

msbuild /t:build /p:Version=YourVersionNumber /p:AssemblyVersion=YourVersionNumber

NuGetパッケージのパッケージ番号

msbuild /t:pack /p:Version=YourVersionNumber   

ありがとうございました!トレジャールームを開くための隠されたレバーがあることを知っていました!古いプロジェクトを新しい.NET SDKに移行しています。自動バージョンインクリメントソリューションを見つける手間をかけずに、これをすばやく実行したいと思っていました。実際、以前の方法との互換性が高いほど、私の場合に適しています。
Ivaylo Slavov

これがIMOの最良の回答です。ビルドツールが適切に機能するようになります。少なくとも、外部メカニズムを使用して、数値をビルドにフィードできます。
Michael Yanni 2018

答えをもう少し広げてください:提案された追加は.csprojの<PropertyGroup>セクションに入る必要があります。そしてもちろん、この素晴らしい答えに感謝します!
GerardV 2018

1
@gerardv、完了しましたが、編集を自分で改善できますstackoverflow.com/help/editing
Michael Freidgeim

61

Visual Studio Team Services / TFSまたはその他のCIビルドプロセスを使用してバージョニングが組み込まれている場合は、msbuildのCondition属性を利用できます。次に例を示します。

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <Version Condition=" '$(BUILD_BUILDNUMBER)' == '' ">0.0.1-local</Version>
    <Version Condition=" '$(BUILD_BUILDNUMBER)' != '' ">$(BUILD_BUILDNUMBER)</Version>
    <TargetFramework>netcoreapp1.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <Folder Include="wwwroot\" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.0.0" />
    <PackageReference Include="Microsoft.AspNetCore" Version="1.1.2" />
    <PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="1.1.2" />
  </ItemGroup>

</Project>

これにより、.NET Coreコンパイラは、BUILD_BUILDNUMBER環境変数が存在する場合は環境変数にあるものを使用する0.0.1-localか、ローカルマシンでビルドを実行する場合はフォールバックするように指示します。


いいですね。環境変数はビルドサーバーで設定できるので、これらの条件はバイナリのアセンブリセットを決定するため、このアプローチが好きです。
jbooker 2017

TFS 2010では機能していないようですが、うまくいけばすぐに廃止されます!
マークアダムソン

悪いソリューションではありませんが、ソリューションに多くのプロジェクトがある場合は少し手間がかかります。
tofutim

良い解決策。ビルド例外が発生しました。私はそれを修正するために設定を少し変更する必要がありました。stackoverflow.com/a/59858009/106227
Stu Harper

これは、.NET Core 2.1.2およびTFS2017U3でうまく機能します
Dave Johnson

15

スター(*)- AssemblyVersion( "1.0。 ")*を使用して、古いAssemblyVersion属性とほぼ同じように機能するソリューションを思いつきました

のAssemblyVersionAssemblyFileVersionは、 MSBuildのプロジェクトである.csproj(ないでファイルAssemblyInfo.cs)プロパティとしてファイルバージョン(生成AssemblyFileVersionAttributeを)とのAssemblyVersion(生成AssemblyVersionAttributeを)。MSBuildプロセスでは、カスタムMSBuildタスクを使用してバージョン番号を生成し、これらのFileVersionプロパティとAssemblyVersionプロパティの値をタスクの新しい値で上書きします。

したがって、最初にカスタムMSBuildタスクGetCurrentBuildVersionを作成します。

public class GetCurrentBuildVersion : Task
{
    [Output]
    public string Version { get; set; }
 
    public string BaseVersion { get; set; }
 
    public override bool Execute()
    {
        var originalVersion = System.Version.Parse(this.BaseVersion ?? "1.0.0");
 
        this.Version = GetCurrentBuildVersionString(originalVersion);
 
        return true;
    }
 
    private static string GetCurrentBuildVersionString(Version baseVersion)
    {
        DateTime d = DateTime.Now;
        return new Version(baseVersion.Major, baseVersion.Minor,
            (DateTime.Today - new DateTime(2000, 1, 1)).Days,
            ((int)new TimeSpan(d.Hour, d.Minute, d.Second).TotalSeconds) / 2).ToString();
    }
}

タスククラスは、Microsoft.Build.Utilities.CoreからMicrosoft.Build.Utilities.Taskクラスを継承します NuGetパッケージます。入力でBaseVersionプロパティ(オプション)を受け取り、生成されたバージョンをVersion出力プロパティで返します。バージョン番号を取得するロジックは、.NETの自動バージョン管理と同じです(ビルド番号は2000年1月1日からの日数で、リビジョンは真夜中から0.5秒です)。

このMSBuildタスクをビルドするには、このクラスで.NET Standard 1.3クラスライブラリプロジェクトタイプを使用します

.csprojファイルは次のようになります。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard1.3</TargetFramework>
    <AssemblyName>DC.Build.Tasks</AssemblyName>
    <RootNamespace>DC.Build.Tasks</RootNamespace>
    <PackageId>DC.Build.Tasks</PackageId>
    <AssemblyTitle>DC.Build.Tasks</AssemblyTitle>
  </PropertyGroup>
 
  <ItemGroup>
    <PackageReference Include="Microsoft.Build.Framework" Version="15.1.1012" />
    <PackageReference Include="Microsoft.Build.Utilities.Core" Version="15.1.1012" />
  </ItemGroup>
</Project>

このタスクプロジェクトは、私のGitHub holajan / DC.Build.Tasksでも利用できます。

次に、このタスクを使用するようにMSBuildをセットアップし、FileVersionプロパティとAssemblyVersionプロパティを設定します。.csprojファイルでは、次のようになります。

<Project Sdk="Microsoft.NET.Sdk">
  <UsingTask TaskName="GetCurrentBuildVersion" AssemblyFile="$(MSBuildThisFileFullPath)\..\..\DC.Build.Tasks.dll" />
 
  <PropertyGroup>
    ...
    <AssemblyVersion>1.0.0.0</AssemblyVersion>
    <FileVersion>1.0.0.0</FileVersion>
  </PropertyGroup>
 
  ...
 
  <Target Name="BeforeBuildActionsProject1" BeforeTargets="BeforeBuild">
    <GetCurrentBuildVersion BaseVersion="$(FileVersion)">
      <Output TaskParameter="Version" PropertyName="FileVersion" />
    </GetCurrentBuildVersion>
    <PropertyGroup>
      <AssemblyVersion>$(FileVersion)</AssemblyVersion>
    </PropertyGroup>
  </Target>
 
</Project>

ここで重要なこと:

  • 言及されたUsingTaskは、DC.Build.Tasks.dllからGetCurrentBuildVersionタスクをインポートします。このdllファイルは、.csprojファイルの親ディレクトリにあると想定しています。
  • 私たちのBeforeBuildActionsProject1ターゲットは、呼び出しタスクは、我々がGetCurrentBuildVersionタスクを呼び出す溶液中でより多くのプロジェクトを持っている場合には、プロジェクトごとに固有の名前を持っていなければならないこと。

このソリューションの利点は、ビルドサーバーでのビルドだけでなく、dotnetビルドまたはVisual Studio からの手動ビルドでも機能することです。


4
特に、コードが自動ビルドマシンで実行される場合DateTime.UtcNowDateTime.Now、メソッドの代わりに使用することをお勧めしますGetCurrentBuildVersionString()。お使いのコンピュータが夏時間に切り替えられた午前2時または午前3時に実行される場合があります。でDateTime.Now、そのシナリオでは、バージョンの観点から後方に行くことがあります。確かに、これはコーナーケースであり、私がうるさいことも認めます。:-)また、すべてのビルドマシンで同じタイムゾーンを構成し、夏時間に調整しない場合にも問題はなくなります。
Manfred 2017

このためのNuGetパッケージはまだありますか?
ジョナサンアレン

@Jonathan Allenいいえ、プロジェクトごとに名前が異なるため、nugetパッケージの計画はありません。コンパイルされたビルドタスクアセンブリgithub.com/holajan/DC.Build.Tasks/tree/master/distフォルダーからダウンロードできます
HolaJan

カスタムコンソールアプリを使用して、サーバーからバージョンをプルし、ビルド前にAssemblyInfo.csファイルを生成しています。このアプローチは、私たちの仕事に最適です。このメソッドを使用して、新しいプロジェクトのパック機能の「バージョン」のバージョンをプッシュできましたか?それもいいですが、nuget.exeを使用してパッケージ化することもできます。公開するためにも必要です。
デビッドリッチー

15

MSBuildプロパティ関数を使用して、現在の日付に基づいてバージョンサフィックスを設定できます。

<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
  <VersionSuffix>pre$([System.DateTime]::UtcNow.ToString(yyyyMMdd-HHmm))</VersionSuffix>
</PropertyGroup>

これにより、PackageName.1.0.0-pre20180807-1711.nupkgのような名前のパッケージが出力されます。

MSBuildプロパティ関数の詳細:https : //docs.microsoft.com/en-us/visualstudio/msbuild/property-functions

Version組み合わせから形成されるVersionPrefixVersionSuffix、または場合はVersionSuffix、空白であるVersionPrefixのみ。

<PropertyGroup>
  <VersionPrefix>1.0.0</VersionPrefix>
</PropertyGroup>

これは本当に便利です
ジェリーニクソン

11

@Gigiは正しいので(今のところ)、上記の回答を受け入れましたが、イライラして次のPowerShellスクリプトを思いつきました。

まず、ソリューションフォルダー(UpdateBuildVersion.ps1)にスクリプトを置きます。

#Get Path to csproj
$path = "$PSScriptRoot\src\ProjectFolder\ProjectName.csproj"

#Read csproj (XML)
$xml = [xml](Get-Content $path)

#Retrieve Version Nodes
$assemblyVersion = $xml.Project.PropertyGroup.AssemblyVersion
$fileVersion = $xml.Project.PropertyGroup.FileVersion

#Split the Version Numbers
$avMajor, $avMinor, $avBuild  = $assemblyVersion.Split(".")
$fvMajor, $fvMinor, $fvBuild = $fileVersion.Split(".")

#Increment Revision
$avBuild = [Convert]::ToInt32($avBuild,10)+1
$fvBuild = [Convert]::ToInt32($fvBuild,10)+1

#Put new version back into csproj (XML)
$xml.Project.PropertyGroup.AssemblyVersion = "$avMajor.$avMinor.$avBuild"
$xml.Project.PropertyGroup.FileVersion = "$fvMajor.$fvMinor.$fvBuild"

#Save csproj (XML)
$xml.Save($path)

これをcsprojファイルに追加しました:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <AssemblyVersion>0.0.1</AssemblyVersion>
    <FileVersion>0.0.1</FileVersion>
    <PreBuildEvent>powershell.exe NonInteractive ExecutionPolicy Unrestricted -command "& {$(SolutionDir)UpdateBuildVersion.ps1}"</PreBuildEvent>
  </PropertyGroup>
</Project>

PreBuildEventと設定しても、ファイルがメモリに読み込まれるまでバージョン番号は更新されないため、次のビルドまでバージョン番号は反映されません。実際、これをPostBuildEventに変更すると、同じ効果が得られます。

次の2つのスクリプトも作成しました:(UpdateMinorVersion.ps1)

#Get Path to csproj
$path = "$PSScriptRoot\src\ProjectFolder\ProjectName.csproj"

#Read csproj (XML)
$xml = [xml](Get-Content $path)

#Retrieve Version Nodes
$assemblyVersion = $xml.Project.PropertyGroup.AssemblyVersion
$fileVersion = $xml.Project.PropertyGroup.FileVersion

#Split the Version Numbers
$avMajor, $avMinor, $avBuild  = $assemblyVersion.Split(".")
$fvMajor, $fvMinor, $fvBuild = $fileVersion.Split(".")

#Increment Minor Version - Will reset all sub nodes
$avMinor = [Convert]::ToInt32($avMinor,10)+1
$fvMinor = [Convert]::ToInt32($fvMinor,10)+1
$avBuild = 0
$fvBuild = 0

#Put new version back into csproj (XML)
$xml.Project.PropertyGroup.AssemblyVersion = "$avMajor.$avMinor.$avBuild"
$xml.Project.PropertyGroup.FileVersion = "$fvMajor.$fvMinor.$fvBuild"

#Save csproj (XML)
$xml.Save($path)

(UpdateMajorVersion.ps1)

#Get Path to csproj
$path = "$PSScriptRoot\src\ProjectFolder\ProjectName.csproj"

#Read csproj (XML)
$xml = [xml](Get-Content $path)

#Retrieve Version Nodes
$assemblyVersion = $xml.Project.PropertyGroup.AssemblyVersion
$fileVersion = $xml.Project.PropertyGroup.FileVersion

#Split the Version Numbers
$avMajor, $avMinor, $avBuild  = $assemblyVersion.Split(".")
$fvMajor, $fvMinor, $fvBuild = $fileVersion.Split(".")

#Increment Major Version - Will reset all sub nodes
$avMajor = [Convert]::ToInt32($avMajor,10)+1
$fvMajor = [Convert]::ToInt32($fvMajor,10)+1
$avMinor = 0
$fvMinor = 0
$avBuild = 0
$fvBuild = 0

#Put new version back into csproj (XML)
$xml.Project.PropertyGroup.AssemblyVersion = "$avMajor.$avMinor.$avBuild"
$xml.Project.PropertyGroup.FileVersion = "$fvMajor.$fvMinor.$fvBuild"

#Save csproj (XML)
$xml.Save($path)

10

dotnetビルド/p:AssemblyVersion=1.2.3.4

私は、「。NET Core(またはそのことについては.NETStandard)プロジェクトでバージョンを制御する方法を誰かが理解しましたか?」CIビルドのコンテキストでこの問題を解決しようとしているこの質問を見つけました。アセンブリバージョンをCIビルド番号に設定する必要がありました。


1
タイトルには、「Visual Studio 2017(.NET Core)での自動バージョン管理」と書かれています。手動でビルドすると、「Visual Studio 2017」に正確に準拠しますか?
JCKödel

4
「.NET Core(または、.NETStandardの場合は.NETStandard)プロジェクトでバージョンを管理する方法を誰かが理解しましたか?」CIビルドのコンテキストでこの問題を解決しようとしているこの質問を見つけました。アセンブリバージョンをCIビルド番号に設定する必要がありました。これが当面の質問に関連していないと感じた場合は、申し訳ありません。
クリスマッケンジー2017

おかげで私にとっては便利なコンポーネントです。これをCIソリューションの一部として使用します
マークアダムソン'26

1
@ChrisMcKenzie:意図を明確にするためにコメントに回答を含める必要があります
Michael Freidgeim

** assemblyinfo.csが指定されておらず、バージョンがcsprojにある場合、これはnetstandardプロジェクトでは機能しません...
tofutim

9

これらの値は.csprojファイルに設定されます。

<PropertyGroup>
    <TargetFramework>netcoreapp1.1</TargetFramework>
    <AssemblyVersion>1.0.6.0</AssemblyVersion>
    <FileVersion>1.0.6.0</FileVersion>
    <Version>1.0.1</Version>
</PropertyGroup>

これらは、プロジェクト設定の[ パッケージ ]タブに移動した場合と同じ値です。私はあなたが*バージョンを自動インクリメントするために使用できるとは思いませんが、あなたにできることは、バージョンを置き換える後処理ステップを導入することです(例えば、継続的インテグレーションの一部として)。


6
これが答えになると思いました。それを増やすための事前ビルド手順を実行できるかどうかを確認します。
Jason H

3
別のスレッドで指摘されているように、新しいcsproj形式を使用すると、assemblyinfoファイルの自動生成をオフにして、独自のファイルを指定できます。私はここnatemcmasterの答えのアドバイスに従い、標準のAssemblyInfo.csファイルを使用:stackoverflow.com/questions/42138418/...
ジェームズ・イービ

5
自動インクリメントを削除したのはなぜですか?それは何年もの間私にとって本当にうまくそして非常に単純に働きました。私はマスターをプッシュし、CIビルドとインクリメントを行い、PSスクリプトを使用してビルド済みDLLからバージョンを直接読み取り、NuGetにプッシュするときにそのバージョンを引数として使用します。とても簡単。今壊れた。
ルークプレット2017

1
@LukePuplett同じです。とてもイライラ!
Shimmy Weitzhandler 2017年

@LukePuplett:参照[「.NET CoreでのAssemblyVersionで#22660をワイルドカードのエラーメッセージが紛らわしい」](github.com/dotnet/roslyn/issues/22660)、彼らは決定論が有益でで説明ビルド考える理由blog.paranoidcoding.com / 2016/04/05 /…コンパイラは確定的である必要があります:同じ入力は同じ出力を生成します#372 < github.com/dotnet/roslyn/issues/372 >
Michael Freidgeim 2017年

5

私は、.NETのコアのバージョン文字列.csproj設定するためのシンプルなCLIツールを作っこちら。GitVersionなどのツールと組み合わせて、CIビルド中に自動的にバージョンバンピングを行うことができます(必要な場合)。


@JasonHありがとう、問題があれば教えてください。
Tagc 2017

天才天才。大好きです!
pms1969 2017

4

GITのタグ付け/説明機能を使用して、GIT設定に基づいて.Net Core / .Net Whateverプロジェクトのバージョン管理を有効にします。

私は、プロジェクトのルートフォルダーにあり、csprojファイルに含まれているPrebuild.targets.xmlファイルを使用しています。

<Project Sdk="Microsoft.NET.Sdk">
  <Import Project="PreBuild.targets.xml" />
  ...
  <PropertyGroup>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>

「GenerateAssembyInfo」タグを使用して、自動アセンブリ情報生成を無効にします。

次に、Prebuild.targets.xmlはCommonAssemblyInfo.csファイルを生成し、GITバージョンに基づいて必要なバージョンタグを含めることができます

注:Prebuilds.targets.xmlを他の場所で見つけたので、クリーンアップする必要はありませんでした。)

Prebuild.targets.xmlファイル:

    <?xml version="1.0" encoding="utf-8" ?>
    <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

      <UsingTask
        TaskName="GetVersion"
        TaskFactory="CodeTaskFactory"
        AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll" >
        <ParameterGroup>
          <VersionString ParameterType="System.String" Required="true" />
          <Version ParameterType="System.String" Output="true" />
          <Commit ParameterType="System.String" Output="true" />
          <VersionSuffix ParameterType="System.String" Output="true" />
        </ParameterGroup>
        <Task>
          <!--<Reference Include="" />-->
          <Using Namespace="System"/>
          <Using Namespace="System.IO"/>
          <Using Namespace="System.Text.RegularExpressions" />
          <Code Type="Fragment" Language="cs">
            <![CDATA[
              var match = Regex.Match(VersionString, @"^(?<major>\d+)\.(?<minor>\d+)(\.?(?<patch>\d+))?-(?<revision>\d+)-(?<commit>[a-z0-9-]+)$");
              int major, minor, patch, revision;
              Int32.TryParse(match.Groups["major"].Value, out major);
              Int32.TryParse(match.Groups["minor"].Value, out minor);
              Int32.TryParse(match.Groups["patch"].Value, out patch);
              Int32.TryParse(match.Groups["revision"].Value, out revision);
              _Version = new Version(major, minor, patch, revision).ToString();
              _Commit = match.Groups["commit"].Value;
            ]]>
          </Code>
        </Task>
      </UsingTask>

      <UsingTask
        TaskName="GitExistsInPath"
        TaskFactory="CodeTaskFactory"
        AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll" >
        <ParameterGroup>
          <Exists ParameterType="System.Boolean" Output="true" />
        </ParameterGroup>
        <Task>
          <!--<Reference Include="" />-->
          <Using Namespace="System"/>
          <Using Namespace="System.IO"/>
          <Using Namespace="System.Text.RegularExpressions" />
          <Code Type="Fragment" Language="cs">
            <![CDATA[
            var values = Environment.GetEnvironmentVariable("PATH");
            foreach (var path in values.Split(';')) {
                var exeFullPath = Path.Combine(path, "git.exe");
                if (File.Exists(exeFullPath)) {
                    Exists = true;
                    return true;
                }
                var cmdFullPath = Path.Combine(path, "git.cmd");
                if (File.Exists(cmdFullPath)) {
                    Exists = true;
                    return true;
            }
            }
            Exists = false;
            ]]>
          </Code>
        </Task>
      </UsingTask>

      <Target Name="CreateCommonVersionInfo" BeforeTargets="CoreCompile">
        <Message Importance="high" Text="CreateCommonVersionInfo" />

        <GitExistsInPath>
          <Output TaskParameter="Exists" PropertyName="GitExists"/>
        </GitExistsInPath>
        <Message Importance="High" Text="git not found!" Condition="!$(GitExists)"/>

        <Exec Command="git describe --tags --long --dirty > $(ProjectDir)version.txt" Outputs="$(ProjectDir)version.txt" WorkingDirectory="$(SolutionDir)" IgnoreExitCode="true" Condition="$(GitExists)">
          <Output TaskParameter="ExitCode" PropertyName="ExitCode" />
        </Exec>
        <Message Importance="high" Text="Calling git failed with exit code $(ExitCode)" Condition="$(GitExists) And '$(ExitCode)'!='0'" />

        <ReadLinesFromFile File="$(ProjectDir)version.txt" Condition="$(GitExists) And '$(ExitCode)'=='0'">
          <Output TaskParameter="Lines" ItemName="OutputLines"/>
        </ReadLinesFromFile>
        <Message Importance="High" Text="Tags: @(OutputLines)" Condition="$(GitExists) And '$(ExitCode)'=='0'"/>

        <Delete Condition="Exists('$(ProjectDir)version.txt')" Files="$(ProjectDir)version.txt"/>

        <GetVersion VersionString="@(OutputLines)" Condition="$(GitExists) And '$(ExitCode)'=='0'">
          <Output TaskParameter="Version" PropertyName="VersionString"/>
          <Output TaskParameter="Commit" PropertyName="Commit"/>
        </GetVersion>

        <PropertyGroup>
          <VersionString Condition="'$(VersionString)'==''">0.0.0.0</VersionString>
        </PropertyGroup>

        <Message Importance="High" Text="Creating CommonVersionInfo.cs with version $(VersionString) $(Commit)" />

        <WriteLinesToFile Overwrite="true" File="$(ProjectDir)CommonAssemblyInfo.cs" Encoding="UTF-8" Lines='using System.Reflection%3B

    // full version: $(VersionString)-$(Commit)

    [assembly: AssemblyVersion("$(VersionString)")]
    [assembly: AssemblyInformationalVersion("$(VersionString)")] 
    [assembly: AssemblyFileVersion("$(VersionString)")]' />

      </Target>
    </Project>

編集:MSBUILDを使用してビルドしている場合、

 $(SolutionDir)

トラブルの原因になるかもしれません

 $(ProjectDir)

代わりに


いいね!VersionSuffixは最終的に設定または使用されますか?それはそうではないようです
マークアダムソン

4

csprojファイル内で以下を実行できます。私は数学を理解していませんでした。私はスタックオーバーフローのどこかでそれを見つけました。しかし、これは機能し、バージョン1.0。*に似たものを提供します。

<PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <FileVersion>1.0.$([System.DateTime]::UtcNow.Date.Subtract($([System.DateTime]::Parse("2000-01-01"))).TotalDays).$([System.Math]::Floor($([MSBuild]::Divide($([System.DateTime]::UtcNow.TimeOfDay.TotalSeconds), 1.32))))</FileVersion>
    <Version>1.0.$([System.DateTime]::UtcNow.Date.Subtract($([System.DateTime]::Parse("2000-01-01"))).TotalDays)</Version>
</PropertyGroup>

3

Visual Studioの自動バージョン拡張機能は、シンプルなユーザーインターフェイスで.Net Coreおよび.Net Standard自動インクリメントをサポートするようになりました。

https://marketplace.visualstudio.com/items?itemName=PrecisionInfinity.AutomaticVersions


1
デモソリューション(Windowsアプリ)を使用して簡単なテストを行いましたが、.net標準プロジェクトでも機能します。これは簡単なテストだったので、必要なすべてのことを行っているかどうかを確認するために、さらに深く調査する必要があります。しかし、あなたは確かにこれを試すことができます。
ArieKanarie

2

特別なパラメータを使用できます dotnet publish -- version-suffix 1.2.3

ファイルバージョンの場合:

<AssemblyVersion Condition=" '$(VersionSuffix)' == '' ">0.0.1.0</AssemblyVersion>
<AssemblyVersion Condition=" '$(VersionSuffix)' != '' ">$(VersionSuffix)</AssemblyVersion>

バージョンの場合:

<Version Condition=" '$(VersionSuffix)' == '' ">0.0.1</Version>
<Version Condition=" '$(VersionSuffix)' != '' ">$(VersionSuffix)</Version>

https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-publish?tabs=netcore21

--version-suffix <VERSION_SUFFIX>     Defines the value for the $(VersionSuffix) property in the project.

2

私を正しい方向に向けてくれた@joelsandに感謝します。

DevOpsビルドの実行時に次の例外が発生したため、彼の答えを少し変更する必要がありました。

The specified version string does not conform to the recommended format - major.minor.build.revision

major.minor.buildセクションの最後に$(BUILD_BUILDNUMBER)を追加する必要がありました。実際のバージョンの重複を排除するには、バージョンプレフィックスも使用します。

<PropertyGroup>
    <VersionPrefix>1.0.3</VersionPrefix>
    <Version Condition=" '$(BUILD_BUILDNUMBER)' == '' ">$(VersionPrefix)-local</Version>
    <Version Condition=" '$(BUILD_BUILDNUMBER)' != '' ">$(VersionPrefix)-$(BUILD_BUILDNUMBER)</Version>
</PropertyGroup>

私はまったく同じ問題を抱えていて、あなたの答えがそれを修正しました。ありがとうございました。
出席者に会う

1

@joelsandからのこの回答は、VSTSで実行されているdotnetコアのバージョン番号を設定するための正しい回答だと思います

この回答の詳細を追加するには、

BUILD_BUILDNUMBERは実際には事前定義された変数です

事前定義された変数には2つのバージョンがあることがわかります。

1つはbuild.xxxxで、もう1つはBUILD_XXXXです。

Environment Variable Namecprojでのみ使用できます。


build.xxxxフロントエンドでパイプライン内での参照に使用されておらずBUILD_XXXX、同じ値ですが、PSで変数を参照するためにわずかに変更された構文が必要ですか?
dst3p
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.