web-dev-qa-db-ja.com

.NET Coreプロジェクトのバージョン番号の設定-CSPROJ-JSONプロジェクトではありません

この質問は 。NET Coreプロジェクトのバージョン番号の設定 に非常に似ていますが、同じではありません。執筆時点での.NET Coreの最新の安定バージョン（1.1）およびVS2017を使用して、.NET CoreはJSONベースのプロジェクトファイルからCSPROJファイルに切り替えました。

だから-私がやろうとしていることは、正しいバージョン番号でビルドにスタンプするために、ビルドの前に何かを変更できるようにしたいCI環境を設定することです.

このような古い属性を使用する場合（SharedAssemblyInfo.csトリック）：

[Assembly: AssemblyFileVersion("3.3.3.3")]
[Assembly: AssemblyVersion("4.4.4.4")]

プロジェクトのどこかで
CS0579 - Duplicate 'System.Reflection.AssemblyFileVersionAttribute'
そして
CS0579 - Duplicate 'System.Reflection.AssemblyVersionAttribute'
構築時のエラー。

少し掘り下げてみると、\obj\Debug\netcoreapp1.1に、ビルドプロセス中に生成された（ビルド前には存在しなかった）このようなファイルがあることがわかりました。

//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//     Runtime Version:4.0.30319.42000
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

using System;
using System.Reflection;

[Assembly: System.Reflection.AssemblyCompanyAttribute("TestApplication")]
[Assembly: System.Reflection.AssemblyConfigurationAttribute("Debug")]
[Assembly: System.Reflection.AssemblyDescriptionAttribute("Package Description")]
[Assembly: System.Reflection.AssemblyFileVersionAttribute("1.1.99.0")]
[Assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.1.99")]
[Assembly: System.Reflection.AssemblyProductAttribute("TestApplication")]
[Assembly: System.Reflection.AssemblyTitleAttribute("TestApplication")]
[Assembly: System.Reflection.AssemblyVersionAttribute("1.1.99.0")]

// Generated by the MSBuild WriteCodeFragment class.

質問-このビットはどうすればいいですか？
だから、これはプロジェクトプロパティの「パッケージページ」に入力された値から何らかの形で生成される必要があることがわかりますが、CIマシンでこれらの値を変更する正しい方法はわかりません。

理想的には、このすべての情報を（Jenkins）CIスクリプトで指定できるようにしたいと思いますが、バージョン番号を設定できるだけで済むと思います。

編集-詳細
最初の答えを読んだ後、私はサービスとNuGETパッケージの両方を作成していることを明確にしたかったのです。そして、すべてをバージョン管理する1つの方法が望ましいと思います。単一のファイルを更新するだけです。

UPDATECSPROJファイルに変更を加えるスクリプトを作成しますが、修正する必要があるセクションがこのように見えるため、私の意見ではかなりハッキングされています。 ..

<PropertyGroup>
 <OutputType>Exe</OutputType>
 <TargetFramework>netcoreapp1.1</TargetFramework>
 <Version>1.0.7777.0</Version>
 <AssemblyVersion>1.0.8888.0</AssemblyVersion>
 <FileVersion>1.0.9999.0</FileVersion>
 <Company>MyCompany</Company>
 <Authors>AuthorName</Authors>
 <Product>ProductName</Product>
 <Description />
 <Copyright>Copyright © 2017</Copyright>
</PropertyGroup>

したがって、ここでの問題は、複数の「PropertyGroup」要素があることです。他のラベルはラベル付けされているように見えますが、CSPROJがどのように組み立てられているかわからないため、これが常に当てはまるとは言えません。

パッケージの詳細は常に入力されるという前提で作業しています。そうしないと、値タグ（上記）がXMLに表示されないため、スクリプトを使用して値を更新できます。値タグがない場合、値を挿入するPropertyGroup要素（および重要なように見える順序もあります。順序を変更すると、VS2017でプロジェクトを読み込むことができなくなります）がわかりません。

私はまだこれよりも良い解決策を求めています！

更新：誰かがこの質問を重複の可能性があるものとしてマークした後（ Visual Studio 2017（.NET Core）の自動バージョン管理 ）-この質問は以前に見たことがなく、今読んでほとんど同じようですただし、バージョン番号を設定したくないだけです。また、この質問への答えは私の問題を解決しません-私が私の質問で尋ねたものだけを尋ねます。私の質問に対する受け入れられた答えは、まさに私の問題を解決するために必要な答えです-したがって、他の質問が最初に来て同じように見えますが、それはまったく役に立ちません。たぶんmodが助けになりますか？

asp.net-corecontinuous-integration.net-coreversioning
40
Jay

/p:PropertyName=Value、dotnet restore、およびdotnet buildの引数としてdotnet packを渡すことにより、コマンドラインから任意のプロパティをオーバーライドできます。

現在、バージョン構成は次のように機能します。Versionが設定されていない場合、VersionPrefix（設定されていない場合のデフォルトは1.0.0）を使用し、存在する場合はVersionSuffixを追加します。

他のすべてのバージョンは、Versionがデフォルトになります。

たとえば、csprojで<VersionPrefix>1.2.3</VersionPrefix>を設定し、dotnet pack --version-suffix beta1を呼び出してYourApp.1.2.3-beta1.nupkgを生成できます（バージョンサフィックスを適用するプロジェクト参照がある場合は、その前にdotnet restore /p:VersionSuffix=beta1を呼び出す必要があります-これはツールの既知のバグです）。

もちろん、カスタム変数も使用できます。いくつかの例については、 このGitHubの問題 を参照してください。

サポートされているアセンブリ属性の完全なリファレンスについては、ビルドロジックのソースコードを参照することをお勧めします here （$()で囲まれた値は使用されるプロパティです）。そして、私はすでにソースについて話しているので、 this はバージョンと他のいくつかのプロパティを構成するロジックです。

51
Martin Ullrich
dotnet build /p:AssemblyVersion=1.2.3.4

それはあなたのために働きますか？

35
Chris McKenzie

直接質問に答えるには：msbuildの新しいSDKは、アセンブリ情報ファイルを自動生成します。 msbuildディレクティブを使用して、これを抑制することができます（サンプルで見るには、project.jsonベースのプロジェクトでdotnet migrateを呼び出します）。

しかし、私の取り扱いを教えてください。同じバージョンを共有する複数のプロジェクトがありました。 VersionPrefixという名前のアイテムを含むプロパティグループを含むversion.propsファイルを追加しました。このファイルは、csprojファイル（Includeステートメント）を介してインクルードしました。また、すべてのAssemblyInfo.csファイルを削除し、SDKに生成させました。

ビルド中にversion.propsファイルを変更します。

7
Thomas

私はCIにJenkins + Octopusを使用していますが、以下は非常にうまく機能しました。

  1. CIビルド番号をパラメーターとして使用したり、デフォルトのプリセットにしたりできる、ビルド前のPowershellスクリプトを用意します。
  2. CIのプロジェクトに別個のnuspecファイルを用意します。
  3. ビルド前スクリプトは、nuspecファイルを最新のビルドバージョンで更新します。
  4. Jenkinsでプロジェクトを公開します。
  5. ＃2のNugetファイルを使用して、nuspecを手動で呼び出します。
  6. nugetパッケージをOctopusにプッシュします。
3
Ignas

私の場合、メインキーは/property:Version=1.2.3.4でした。そして、次のコマンドラインが仕事をしました：

dotnet build SolutionName.sln -c Release /property:Version=1.2.3.4

これにより、アセンブリのデフォルトバージョンが上書きされます。

3
maytham-ɯɐɥʇʎɐɯ

MsBuild 2017は、プロジェクトファイルに含まれていないアセンブリ情報を生成します。

Msbuildターゲットファイルを読み取ることができる場合は、次を参照してください。

[VS Install Dir] \MSBuild\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.GenerateAssemblyInfo.targets

プロジェクトファイル内のプロパティを使用して、生成されたアセンブリ情報を無効にして、生成されたツールと重複しないようにすることができます。

  • <GenerateAssemblyInfo>（このプロパティはすべてアセンブリ情報の生成をオン/オフします）
  • <GenerateAssemblyCompanyAttribute>
  • <GenerateAssemblyConfigurationAttribute>
  • <GenerateAssemblyCopyrightAttribute>
  • <GenerateAssemblyDescriptionAttribute>
  • <GenerateAssemblyFileVersionAttribute>
  • <GenerateAssemblyInformationalVersionAttribute>
  • <GenerateAssemblyProductAttribute>
  • <GenerateAssemblyTitleAttribute>
  • <GenerateAssemblyVersionAttribute>
  • <GenerateNeutralResourcesLanguageAttribute>
3
Anh Phan Tuan

here と答えたように、*。csproj-style .NET Coreプロジェクトのバージョン管理に使用できる dotnet-setversion というCLIツールを作成しました。

CIビルド中に、GitVersionまたは別のツールを使用してプロジェクトのバージョン番号を確認し、プロジェクトルートディレクトリでdotnet-setversion $YOUR_VERSION_STRINGを呼び出すことができます。

1
Tagc

引数として/ p：PropertyName = Valueを渡しても機能しません（ASP.Net Core 2.0 Web App）。 marketpaceでManifest Versioning Build Tasksを見つけました： https://marketplace.visualstudio.com/items?itemName=richardfennellBM.BM-VSTS-Versioning-Task

0
Michael Giger