Visual Studio 2017'de (.NET Core) Otomatik Sürüm Oluşturma


112

Bir .NETCoreApp 1.1'de (Visual Studio 2017) sürümleri otomatik olarak artırmanın bir yolunu bulmaya çalışırken birkaç saatin daha iyi kısmını harcadım.

AssemblyInfo.cs dosyasının klasörde dinamik olarak oluşturulduğunu biliyorum: obj/Debug/netcoreapp1.1/

Şu eski yöntemi kabul etmez: [assembly: System.Reflection.AssemblyFileVersionAttribute("1.0.0.*")]

Projeyi pakete ayarlarsam, sürümleri orada ayarlayabilirim, ancak bu AssemblyInfo.cs dosyasını oluşturmak için kullanılıyor gibi görünüyor.

Sorum şu ki, .NET Core (veya bu konuda .NETStandard) projelerinde sürümün nasıl kontrol edileceğini anlayan var mı?


Bununla ne kadar ilerlediğinizi bilmiyorum, ancak neredeyse aynı soruyu farklı bir şekilde sordum gibi görünüyor ( stackoverflow.com/a/43280282/685341 ) - Belki bu sorunun kabul edilen cevabı size yardımcı olur; Sadece geçebilir /p:bayrağı dotnet msbuild... Yapınızın yazısı ve set sürümü, şirket, telif tüm bu iyi şeyler.
Jay

2
Bilgi için teşekkürler. Bu sadece ek seçenekler açar.
Jason H

Daha önce * AssemblyFileVersion için değil, AssemblyVersion için destekleniyordu - bkz.Visual Studio kullanırken dosya oluşturma sürümünü otomatik olarak artırabilir miyim?
Michael Freidgeim

4
FWIW, derleme sürümündeki joker karakter desteklenmez çünkü bu yeni proje için derleyicinin "deterministik" modu varsayılan olarak etkindir. Otomatik artış determinizmi bozacağından (aynı girdi> aynı çıktı) bu modda izin verilmez. Kullanmak <Deterministic>False</Deterministic>için csproj'da ayarlayabilirsiniz . (veya hesaplamak için başka bir MSbuild mantığını kullanın <VersionPrefix>/ <Version>)
Martin Ullrich

Yanıtlar:


23

VS2017'de csproj yapılandırma formatını kullanan bir Net Core uygulaması için bir sürüm artırıcı arıyordum.

Project.json formatı için çalışan ancak .csproj formatı için bir çözüm bulmakta zorlanan dotnet bump adlı bir proje buldum. Yazar, dotnet çıkıntısının aslında .csproj biçiminin çözümünü buldu ve buna MSBump adı verildi.

GitHub'da bunun için bir proje var:

https://github.com/BalassaMarton/MSBump

Kodu görebileceğiniz yer ve Nuget'te de mevcut. Sadece Nuget'te MSBump'ı arayın.


1
MSBump'ın en son 2.1.0 sürümünü kullanmanızı öneririm, Konfigürasyonların değiştirilmesini daha iyi destekler ve ayrıca sonraki sürümün değil (önceki sürüm gibi) mevcut yapının sürümünü ayarlar.
Márton Balassa

Artık MSBuild'i de desteklediğini görüyorum, oysa öncesinde görsel stüdyo gerektiriyor.
27'de ravetroll

2
Evet, ayrıca çoklu hedefleme projelerini de destekler.
Márton Balassa

4
GitVersioning kullanmayı düşünün. CI ortamınızda çalıştırmak uygun olabilir. github.com/AArnott/Nerdbank.GitVersioning
Henrique

1
MSBump, hiçbir şeyi değiştirmemiş olsanız bile her derlemede sürümü artırır, bu uzun vadede birçok soruna neden olur. Ve bazen sürümler senkronize olmaz ve bir sürüm diğerinin arkasında kalır.
Konrad

68

<Deterministic>False</Deterministic><PropertyGroup>.Csproj bölümünün içine ekleyin 

AssemblyVersion * 'ı çalıştırmaya yönelik geçici çözüm, ".Net Core # 22660 üzerindeki [AssemblyVersion]' da joker karakter için kafa karıştırıcı hata mesajı" bölümünde açıklanmaktadır.

Joker karakterlere yalnızca yapı belirleyici değilse izin verilir, bu .Net Core projeleri için varsayılan değerdir. <Deterministic>False</Deterministic> Csproj'a eklemek  sorunu çözer.

.Net Core Geliştiricilerinin, http://blog.paranoidcoding.com/2016/04/05/deterministic-builds-in-roslyn.html ve Derleyicilerde açıklanan Deterministic Builds'ı yararlı olarak değerlendirmesinin nedenleri belirleyici olmalıdır: aynı girdiler aynı çıktıları üretir # 372

Bununla birlikte, TeamCity, TFS veya diğer CI / CD araçlarını kullanıyorsanız, sürüm numarasını onlar tarafından kontrollü ve artırılmış tutmak ve bir parametre olarak oluşturmak için geçmek muhtemelen daha iyidir (diğer yanıtlarda önerildiği gibi), örn.

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

NuGet paketleri için paket numarası

msbuild /t:pack /p:Version=YourVersionNumber   

Teşekkür ederim! Hazine odasını açmak için gizli bir kol olduğunu biliyordum! Eski bir projeyi yeni .NET SDK'ya geçiriyorum ve bunu, otomatikleştirilmiş sürüm artırma çözümleri bulma zahmetine girmeden gerçekten hızlı bir şekilde yapmak istedim. Aslında eski yöntemlerle ne kadar uyumlu olursa benim durumum için o kadar iyi.
Ivaylo Slavov

Bu en iyi cevap IMO'dur. Yapım aletlerinin düzgün çalışmasını sağlar. En azından şu anda sayıyı yapıya eklemek için harici bir mekanizma kullanabilirim.
Michael Yanni

Lütfen yanıtınızı biraz daha genişletin: Önerilen eklemenin .csproj'un <PropertyGroup> bölümüne gitmesi gerekir. Ve bu harika cevap için teşekkürler, tabii ki!
GerardV

1
@gerardv, bitti, ancak düzenlemeleri kendi kendinize iyileştirebilirsiniz stackoverflow.com/help/editing
Michael Freidgeim

62

Yerleşik sürüm oluşturmaya sahip olmak için Visual Studio Team Services / TFS veya başka bir CI oluşturma işlemi kullanıyorsanız, msbuild Conditionözniteliğini kullanabilirsiniz , örneğin:

<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>

Bu, .NET Core derleyicisine, BUILD_BUILDNUMBERvarsa ortam değişkeninde bulunan her şeyi kullanmasını veya 0.0.1-localyerel makinenizde bir derleme yapıyorsanız geri dönmesini söyleyecektir .


Güzel, bu yaklaşımı beğendim çünkü ortam değişkenleri sadece inşa sunucusunda ayarlanabilirken, bu şartlar ikili dosyalardaki montaj setini belirler.
jbooker

TFS 2010'da işe yaramıyor gibi görünüyor, ancak umarım yakında hareket ediyoruz!
Mark Adamson

Fena bir çözüm değil, ancak çözümün çok fazla projesi varsa biraz iş olabilir.
tofutim

Güzel çözüm. Yine de bir Yapı istisnası aldım. Düzeltmek için yapılandırmayı biraz değiştirmem gerekti. stackoverflow.com/a/59858009/106227
Stu Harper

Bu, .NET Core 2.1.2 ve TFS2017U3 ile harika çalışıyor
Dave Johnson

16

Yıldız (*) - AssemblyVersion ("1.0. ") * İle eski AssemblyVersion özniteliğiyle neredeyse aynı şekilde çalışan bir çözüm buldum

Değerleri AssemblyVersion ve AssemblyFileVersion MSBuild proje olduğunu .Csproj (değil de dosyaya AssemblyInfo.cs mülkiyet gibi) DosyaSürümü (üretir AssemblyFileVersionAttribute ) ve AssemblyVersion (üretir AssemblyVersionAttribute ). MSBuild sürecinde, sürüm numaralarını oluşturmak için özel MSBuild görevimizi kullanıyoruz ve ardından bu FileVersion ve AssemblyVersion değerlerini geçersiz kılıyoruz. özelliklerinin yeni değerlerle .

Bu yüzden önce özel MSBuild görevimizi GetCurrentBuildVersion oluşturuyoruz :

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();
    }
}

Dan Görev sınıf devralır Microsoft.Build.Utilities.Task gelen sınıfına Microsoft.Build.Utilities.Core NuGet paketinden . Girişte BaseVersion özelliğini (isteğe bağlı) alır ve Version çıktı özelliğinde üretilen sürümü döndürür. Sürüm numaralarını alma mantığı, .NET otomatik sürüm oluşturma ile aynıdır (Derleme numarası, 1/1 / 2000'den itibaren gün sayısıdır ve Revizyon, gece yarısından itibaren yarım saniyedir).

Bu MSBuild görevini oluşturmak için , bu sınıfla birlikte .NET Standard 1.3 sınıf kitaplığı proje türünü kullanıyoruz.

.csproj dosyası şöyle görünebilir:

<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>

Bu görev projesi ayrıca GitHub holajan / DC.Build.Tasks'ımda da mevcuttur.

Şimdi MSBuild'i bu görevi kullanacak ve FileVersion ve AssemblyVersion özelliklerini ayarlayacak şekilde kuruyoruz . .Csproj dosyasında şöyle görünür:

<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>

Burada önemli şeyler:

  • UsingTask'dan bahsedildi GetCurrentBuildVersion görevini DC.Build.Tasks.dll'den içe aktarır . Bu dll dosyasının .csproj dosyanızdaki üst dizinde bulunduğunu varsayar.
  • GetCurrentBuildVersion görevini çağıran çözümde daha fazla projemiz olması durumunda, görevi çağıran BeforeBuildActionsProject1 Hedefimiz proje başına benzersiz bir ada sahip olmalıdır.

Bu çözümün avantajı, yalnızca derleme sunucusundaki derlemelerde değil, aynı zamanda dotnet derlemesinden veya Visual Studio'dan manuel derlemelerde de çalışmasıdır .


4
Özellikle kod otomatikleştirilmiş yapı makinelerinde çalıştırılıyorsa, yöntem DateTime.UtcNowyerine kullanılmasını öneririm . Bilgisayarınız gün ışığından yararlanma saatine geçiş yaptığında sabah 02.00 veya 03.00'da çalışabilirler. Bu senaryoda, sürüm açısından geriye doğru gidiyor olabilirsiniz. Kuşkusuz, bu bir köşe davası ve seçici olduğumu da kabul ediyorum. :-) Ayrıca, tüm yapı makinelerinde aynı saat dilimini yapılandırırsanız ve gün ışığından yararlanma saatine ayarlamazsanız da sorun ortadan kalkar. DateTime.NowGetCurrentBuildVersionString()DateTime.Now
Manfred

Bunun için henüz bir NuGet paketi var mı?
Jonathan Allen

@Jonathan Allen Hayır, her projede farklı isimlerden dolayı nuget paketi için bir planım yok. Derlenmiş derleme görevi derlemesini github.com/holajan/DC.Build.Tasks/tree/master/dist klasöründen
indirebilirsiniz

Sürümümüzü bir sunucudan çekmek ve derlemelerden önce AssemblyInfo.cs dosyasını oluşturmak için özel bir konsol uygulaması kullanıyoruz. Bu yaklaşım, yaptığımız iş için mükemmel. Bu yöntemi, yeni projelerin paket özelliğinin "Sürüm" kısmındaki sürümü itmek için kullanabildiniz mi? Güzel olurdu, ama aynı zamanda yayınlamak için ihtiyacımız olacağı için nuget.exe'yi de paketlemek için kullanmaya geri dönebiliriz.
David Ritchie

15

Sürüm sonekini geçerli tarihe göre ayarlamak için bir MSBuild özellik işlevi kullanabilirsiniz:

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

Bu, aşağıdaki gibi bir adda bir paket çıkarır : PaketAdı.1.0.0-pre20180807-1711.nupkg .

MSBuild özellik işlevleri hakkında daha fazla ayrıntı: https://docs.microsoft.com/en-us/visualstudio/msbuild/property-functions

VersionKombinasyonundan oluşan VersionPrefixve VersionSuffix, ya da, eğer VersionSuffix, boştur VersionPrefixancak.

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

Bu gerçekten kullanışlı
Jerry Nixon

12

Yukarıdaki cevabı kabul ettim çünkü @Gigi doğru (şu an itibariyle) ama sinirlenmiştim ve aşağıdaki PowerShell Scriptlerini buldum.

İlk önce komut dosyasını çözüm klasörümde (UpdateBuildVersion.ps1) var:

#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)

Bunu csproj dosyasına ekledim:

<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>

Bir PreBuildEvent olarak ayarlanmış olsa bile, gerçek şu ki, sürüm numaraları dosya belleğe yüklendikten SONRA güncellenene kadar güncellenmez, bu nedenle sürüm numarası bir sonraki yapıya kadar yansıtılmaz. Aslında, bunu bir PostBuildEvent olarak değiştirebilirsiniz ve aynı etkiye sahip olacaktır.

Ayrıca aşağıdaki iki komut dosyasını da oluşturdum: (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 build /p:AssemblyVersion=1.2.3.4

Yanıt veriyordum: ".NET Core (veya bu konuda .NETStandard) projelerinde sürümü nasıl kontrol edeceğini kimse bulmuş mu?" Bu soruyu bir CI yapısı bağlamında bu sorunu çözmeye çalışırken buldum. Montaj sürümünü CI yapı numarasına ayarlamak istedim.


1
Başlık, "Visual Studio 2017'de (.NET Core) Otomatik Sürüm Oluşturma" diyor. El ile oluşturmak tam olarak nerede "Visual Studio 2017" ile uyumludur?
JCKödel

4
Yanıt veriyordum: ".NET Core (veya bu konuda .NETStandard) projelerinde sürümü nasıl kontrol edeceğini kimse bulmuş mu?" Bu soruyu bir CI yapısı bağlamında bu sorunu çözmeye çalışırken buldum. Montaj sürümünü CI yapı numarasına ayarlamak istedim. Bunun eldeki soruyla alakalı olmadığını düşünüyorsanız özür dilerim.
Chris McKenzie

Benim için faydalı bir bileşen, teşekkürler. Bunu bir CI çözümünün parçası olarak kullanacağım
Mark Adamson

1
@ChrisMcKenzie: Niyetinizi netleştirmek için yorumunuz cevabınıza dahil edilmelidir
Michael Freidgeim

** bu benim için netstandard projelerinde assemblyinfo.cs belirtilmediğinde ve sürüm csproj'da olduğunda çalışmıyor ...
tofutim

9

Bu değerler artık .csprojdosyada ayarlanmıştır :

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

Bunlar , proje ayarlarında Paket sekmesine giderseniz gördüğünüz değerlerin aynısıdır . Kullanabileceğin sanmıyorum iken *sürümünü autoincrement için, ne yapabildiğini is sizin için sürümlerini yerini bir post-işleme adımını tanıtmak (örneğin sizin sürekli entegrasyon bir parçası olarak).


6
Cevabın bu olacağından korkuyordum. Bunu artırmak için bir ön oluşturma adımı yapıp yapamayacağımı göreceğim.
Jason H

3
Başka bir iş parçacığında belirtildiği gibi, yeni csproj formatı, assemblyinfo dosyasının otomatik olarak oluşturulmasını kapatmanıza ve sizin için kendinizinkini belirlemenize izin verir. Burada natemcmaster'ın cevabının tavsiyesini takip ettim ve standart bir AssemblyInfo.cs dosyası kullandım: stackoverflow.com/questions/42138418/…
James Eby

5
Otomatik artırmayı neden kaldırdılar? Yıllarca benim için gerçekten iyi ve çok basit bir şekilde çalıştı. Master, CI derlemeleri ve artışları gönderiyorum, ardından sürüm bazı PS komut dosyası kullanılarak doğrudan yerleşik DLL'den okunur, ardından NuGet'e gönderirken bu sürümü bir arg olarak kullanır. Çok basit. Şimdi kırıldı.
Luke Puplett

1
@LukePuplett burada aynı. çok sinir bozucu!
Shimmy Weitzhandler

@LukePuplett: Bkz. [".Net Core # 22660'daki AssemblyVersion'da joker karakter için kafa karıştırıcı hata mesajı"] ( github.com/dotnet/roslyn/issues/22660 ), Blog.paranoidcoding.com'da açıklanan Deterministic Builds'ı yararlı bulmalarının nedenleri / 2016/04/05 /… ve Derleyiciler belirleyici olmalıdır: aynı girdiler aynı çıktıları üretir # 372 < github.com/dotnet/roslyn/issues/372 >
Michael Freidgeim

5

Burada .csproj .NET Core sürüm dizelerini ayarlamak için basit bir CLI aracı yaptım . Peşinde olduğunuz şey buysa, CI yapıları sırasında otomatik sürüm çarpması için GitVersion gibi araçlarla birleştirebilirsiniz.


@JasonH Teşekkürler, bununla ilgili herhangi bir sorununuz olursa bana bildirin.
Tagc

Allahın belası dahi. Sevdim!
pms1969

4

.Net Core / .Net'inizin sürümlemesini etkinleştirmek için GIT kurulumunuza bağlı olarak hangi proje olursa olsun, GIT'in etiketlerini / işlevini açıklayın.

Projenin kök klasöründe bulunan ve csproj dosyasına dahil edilen bir Prebuild.targets.xml dosyası kullanıyorum:

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

Otomatik derleme bilgisi oluşturmayı devre dışı bırakmak için "GenerateAssembyInfo" etiketini kullanın.

Ardından Prebuild.targets.xml, GIT sürümünüze göre istediğiniz sürüm etiketlerini dahil edebileceğiniz bir CommonAssemblyInfo.cs dosyası oluşturur.

NOT: Prebuilds.targets.xml dosyasını başka bir yerde buldum, bu yüzden temizlemeyi zahmet etmedim.)

Prebuild.targets.xml dosyası:

    <?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>

DÜZENLEME: MSBUILD kullanarak oluşturuyorsanız

 $(SolutionDir)

Sana sorun çıkarabilir, kullan

 $(ProjectDir)

yerine


Güzel! VersionSuffix kuruluyor veya kullanılmaya başlanıyor mu? Öyle görünmüyor
Mark Adamson

4

Aşağıdakileri csproj dosyası içinde yapabilirsiniz. Matematiği anlamadım. Bunu stackoverflow'da başka bir yerde buldum. Ancak bu çalışır ve size sürüm için 1.0. * İle benzer bir şey verir.

<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 için Otomatik Sürümler uzantısı artık basit bir kullanıcı arabiriminde .Net Core ve .Net Standard otomatik artırmayı desteklemektedir.

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


1
Demo çözümü (Windows uygulaması) ile hızlı bir test yaptım ve .net standart projesiyle de çalışıyor. Hızlı bir testti, bu yüzden istediğimiz her şeyi yapıp yapmadığını kontrol etmek için daha derine dalmalıyız. Ama bunu kesinlikle deneyebilirsin.
ArieKanarie

3

Beni doğru yöne yönlendirdiği için @joelsand'e teşekkürler.

DevOps Derlemesi çalışırken verdiği gibi cevabını biraz değiştirmek zorunda kaldım, şu istisnayı aldım

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

$ (BUILD_BUILDNUMBER) öğesini major.minor.build bölümünün sonuna eklemek zorunda kaldım. Gerçek sürümün kopyasını kaldırmak için ayrıca bir sürüm öneki kullanıyorum:

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

Ben de aynı sorunu yaşadım ve cevabınız onu çözdü. Teşekkür ederim.
Toplantı Katılımcısı

2

İçin özel parametre kullanabiliriz dotnet publish -- version-suffix 1.2.3

Dosya sürümü için:

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

Versiyon için:

<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.

1

Bunu düşünmek Cevap @joelsand dotnet çekirdek VSTS çalışan sürüm numarasını ayarlamak için Doğru cevap

Bu cevaba daha fazla bilgi eklemek için,

BUILD_BUILDNUMBERaslında önceden tanımlanmış bir değişkendir .

Önceden tanımlanmış değişkenin 2 versiyonu olduğu ortaya çıktı.

Biri build.xxxx, diğeri BUILD_XXXX.

Yalnızca Environment Variable Namecproj'de kullanabilirsiniz .


Is not build.xxxxpipeline'da referans için ön ucunda kullanılan ve BUILD_XXXXaynı değerdir kısmen değiştirilmiş sözdizimi ile PS değişkeni referans için gerekli?
dst3p
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.