Czy mogę automatycznie zwiększyć wersję kompilacji pliku podczas korzystania z programu Visual Studio?

358

Zastanawiałem się, jak mogę automatycznie zwiększyć kompilację (i wersję?) Moich plików za pomocą Visual Studio (2005).

Jeśli sprawdzę właściwości powiedzmy C:\Windows\notepad.exe, zakładka Wersja pokazuje „Wersja pliku: 5.1.2600.2180”. Chciałbym uzyskać te fajne liczby również w wersji mojej biblioteki DLL, a nie w wersji 1.0.0.0, co, powiedzmy, jest trochę nudne.

Próbowałem kilku rzeczy, ale nie wygląda to na gotową funkcjonalność, a może po prostu szukam w niewłaściwym miejscu (jak zwykle).

Pracuję głównie przy projektach internetowych ....

Patrzyłem na oba:

  1. http://www.codeproject.com/KB/dotnet/Auto_Increment_Version.aspx
  2. http://www.codeproject.com/KB/dotnet/build_versioning.aspx

i nie mogłem uwierzyć, że tyle wysiłku, aby coś zrobić, to standardowa praktyka.

EDYCJA: O ile mogę powiedzieć, nie działa w VS2005 ( http://www.codeproject.com/KB/dotnet/AutoIncrementVersion.aspx )

pomimo
źródło
1
wydaje się, że dzika karta działa tylko w przypadku AssemblyVersion, ale nie w przypadku AssemblyFileVersion w VS 2005
dotnetcoder
Czy istnieją jakieś rozwiązania tego problemu, które działają dla projektów C ++ w VS2005? Wszystkie odpowiedzi wydają się odnosić się do .Net. Powiązane pytanie . Dzięki
Deanna
W projektach .Net Core auto-inkrement AssemblyVersion domyślnie nie działa. Musisz dodać <Deterministic> False </Deterministic> do csproj. Zobacz temat Automatyczne wersjonowanie w Visual Studio 2017 (.NET Core)
Michael Freidgeim

Odpowiedzi:

434

W Visual Studio 2008 następujące prace.

Znajdź plik AssemblyInfo.cs i znajdź te 2 linie:

[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

Możesz spróbować zmienić to na:

[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion("1.0.*")]

Ale to nie da pożądanego rezultatu, skończysz z wersją produktu 1.0. * I wersją pliku 1.0.0.0 . Nie to, czego chcesz!

Jeśli jednak usuniesz drugą z tych linii i po prostu masz:

[assembly: AssemblyVersion("1.0.*")]

Następnie kompilator ustawi Wersję pliku na równą Wersji produktu i uzyskasz pożądany wynik automatycznego przyrostu produktu i wersji pliku, które są zsynchronizowane. Np. 1.0.3266.92689

Sam Meldrum
źródło
2
Działa to tak samo dobrze, jak wszystko inne, i działa w VS2005. Miałem nadzieję na jakąś racjonalną liczbę, taką jak 1.0.1.56, zamiast tego dostaję 1.0.3266.30135, ale przynajmniej wzrasta (choć o jakąś losową liczbę: D)
skontroluj
14
och, właśnie to przeczytałem: automatycznie wypełni dwie ostatnie cyfry datą (w dniach od pewnego momentu) i godziną (pół sekundy od północy)
inspite
20
Niezłe wezwanie do usunięcia atrybutu AssemblyFileVersion, aby to zadziałało!
David Faivre
76
Zdaję sobie sprawę, że to stare pytanie, ale chciałem dodać ten komentarz dla innych, którzy znajdą drogę do tej odpowiedzi. Jeśli zwiększysz wartość AssemblyVersion, każdy projekt korzystający z biblioteki DLL będzie musiał zostać ponownie skompilowany. Jeśli jednak nie zmienisz wartości AssemblyVersion i zwiększysz wartość AssemblyFileVersion, możesz zamienić nową bibliotekę DLL bez konieczności ponownej kompilacji tego, co z niej korzysta. Więc zadaj sobie to pytanie, czy to tylko nowa wersja, czy wypuszczam nową wersję?
onefootswill
27
@ DD59 „Kompilacja” to liczba dni od 1 stycznia 2000 r .; „Rewizja” to sekundy od północy podzielone przez 2 (nie pół sekundy, ale dwie sekundy). Zobacz tutaj: stackoverflow.com/a/3387167/11545
Cristian Diaconescu
154

otwórz plik AssemblyInfo.cs i zmień

// 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.*")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

do

[assembly: AssemblyVersion("1.0.*")]
//[assembly: AssemblyFileVersion("1.0.0.0")]

możesz to zrobić w IDE, przechodząc do projektu -> właściwości -> informacje o złożeniu

Pozwoli to jednak tylko na automatyczne zwiększenie wersji zestawu i da ci

Wersja pliku zespołu: Symbol wieloznaczny („*”) jest niedozwolony w tym polu

pole wiadomości, jeśli spróbujesz umieścić * w polu wersji pliku.

Więc po prostu otwórz plik assemblyinfo.cs i zrób to ręcznie.

Hath
źródło
Tak, właśnie spotkałem „” Wersja pliku zespołu: symbol wieloznaczny („*”) jest niedozwolony w tym polu ”, dlatego wygrałeś swoją metodę przez zielony haczyk: D
inspect
3
to działa: [zespół: AssemblyVersion („1.0. *”)] // [zespół: AssemblyFileVersion („1.0.0.0”)]
inspect
4
Zmiana numeru AssemblyVersion podczas cyklu wydania nie jest pożądana. Zamiast tego należy zmienić AssemblyFileVersion. Zobacz mój post na blogu na ten temat: philippetruche.wordpress.com/2008/08/12/... Zobacz także doskonały post Suzanne Cook na temat tego, kiedy zmieniać numery: blogs.msdn.com/b/suzcook/archive/2003/05/ 29 / 57148.aspx
Philippe
46
Będę ostrożny, używając *, przestanie działać 4 czerwca 2179, kiedy dzień osiągnie 65536
Lloyd Powell,
3
@Shimmy: Dodaj <Deterministic> False </Deterministic> do .csproj Auto Versioning w Visual Studio 2017 (.NET Core)
Michael Freidgeim
53

Inną opcją zmiany numerów wersji w każdej kompilacji jest użycie zadania Wersja MSBuild.Community.Tasks . Wystarczy pobrać ich instalator, zainstalować go, a następnie dostosować następujący kod i wkleić go <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />w .csprojpliku:

<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
<Target Name="BeforeBuild">
    <Version VersionFile="Properties\version.txt" Major="1" Minor="0" BuildType="Automatic" StartDate="12/31/2009" RevisionType="BuildIncrement">
      <Output TaskParameter="Major" PropertyName="Major" />
      <Output TaskParameter="Minor" PropertyName="Minor" />
      <Output TaskParameter="Build" PropertyName="Build" />
      <Output TaskParameter="Revision" PropertyName="Revision" />
    </Version>
    <AssemblyInfo CodeLanguage="CS"
                  OutputFile="Properties\VersionInfo.cs"
                  AssemblyVersion="$(Major).$(Minor)"
                  AssemblyFileVersion="$(Major).$(Minor).$(Build).$(Revision)" />
</Target>

Uwaga: Dostosuj właściwość StartDate do swoich ustawień regionalnych. Obecnie nie wykorzystuje niezmiennej kultury.

W przypadku trzeciej kompilacji 14 stycznia 2010 r. Utworzy to VersionInfo.csnastępującą treść:

[assembly: AssemblyVersion("1.0")]
[assembly: AssemblyFileVersion("1.0.14.2")]

Plik ten należy następnie dodać do projektu (poprzez Dodaj istniejący element ), AssemblyVersiona AssemblyFileVersionlinie i należy usunąć zAssemblyInfo.cs .

Różne algorytmy zmiany komponentów wersji są opisane w $(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.chmi Właściwościach wersji .

chrześcijanin
źródło
2
To najlepszy sposób, jaki widziałem, aby obejść ten okropny fakt, że struktury FileVersion używają 16-bitowych liczb całkowitych.
Mike Post
1
Miałem problemy z instalacją w VS2012 przy użyciu Konsoli pakietów, dlatego zalecamy używanie pobranych nocnych instalatorów msi ze strony github.com/loresoft/msbuildtasks/downloads . Działa kopiuj / wklej z powyższego. Dzięki!
DaveO
Po odmowie i edycji w tym poście: „Możesz także sprawdzić ten loresoft.com/projects/msbuildtasks/… , może poprawić podstawową funkcjonalność opisaną wcześniej”.
radu florescu
1
To nie jest realne rozwiązanie dla tych, którzy budują z TFS. Ostatecznie doda to oczekującą edycję do plików VersionInfo.cs i version.txt. Dla mnie nie jest pożądane, aby edytować każdą wersję.
JDennis
@JDennis zobacz tutaj wskazówki dotyczące wersji TFS ...
Christian
25

Wymyśliłem rozwiązanie podobne do chrześcijan, ale bez zależności od zadań społeczności MSBuild, nie jest to dla mnie opcja, ponieważ nie chcę instalować tych zadań dla wszystkich naszych programistów.

Generuję kod i kompiluję do zestawu i chcę automatycznie zwiększać numery wersji. Nie mogę jednak użyć VS 6.0. * AssemblyVersion sztuczka, ponieważ automatycznie zwiększa liczbę kompilacji każdego dnia i psuje kompatybilność ze złożeniami, które używają starszej liczby kompilacji. Zamiast tego chcę mieć zakodowane na stałe AssemblyVersion, ale automatycznie zwiększające wartość AssemblyFileVersion. Osiągnąłem to, określając AssemblyVersion w AssemblyInfo.cs i generując VersionInfo.cs w MSBuild w ten sposób,

  <PropertyGroup>
    <Year>$([System.DateTime]::Now.ToString("yy"))</Year>
    <Month>$([System.DateTime]::Now.ToString("MM"))</Month>
    <Date>$([System.DateTime]::Now.ToString("dd"))</Date>
    <Time>$([System.DateTime]::Now.ToString("HHmm"))</Time>
    <AssemblyFileVersionAttribute>[assembly:System.Reflection.AssemblyFileVersion("$(Year).$(Month).$(Date).$(Time)")]</AssemblyFileVersionAttribute>
  </PropertyGroup>
  <Target Name="BeforeBuild">
    <WriteLinesToFile File="Properties\VersionInfo.cs" Lines="$(AssemblyFileVersionAttribute)" Overwrite="true">
    </WriteLinesToFile>
  </Target>

Spowoduje to wygenerowanie pliku VersionInfo.cs z atrybutem Assembly dla AssemblyFileVersion, w którym wersja jest zgodna ze schematem YY.MM.DD.TTTT z datą kompilacji. Musisz dołączyć ten plik do swojego projektu i budować z nim.

Boog
źródło
Czy MSBuild obsługuje zmienne? Lepiej byłoby zastosować [System.DateTime]::Nowjedną z nich, w przeciwnym razie istnieje warunek wyścigu, który może spowodować użycie starego numeru kompilacji, jeśli buduje się blisko północy.
Edward Brey,
Czy zdefiniowałeś te cztery właściwości zamiast łączyć je w jedną DateTime.ToStringdla celów demonstracyjnych, czy jest jakiś konkretny powód?
mafu
Jeśli Twoje wydarzenie BeforeBuild nie uruchomi się w VS2017, sprawdź stackoverflow.com/questions/43921992/...
Rhys Jones
To rozwiązanie najlepiej pasuje do wszystkich odpowiedzi tutaj. Problem jednak polega na tym, że znacznik czasu (lub zawartość pliku versioninfo.cs) nie aktualizuje się, jeśli projekt zostanie utworzony po raz drugi, co powinno dać inną minutę. Jeśli zamknę i ponownie załaduję projekt, znacznik czasu zostanie zaktualizowany. Czy to błąd MSBuild? @Boog
Cary
12

Aby uzyskać numery wersji, spróbuj

 System.Reflection.Assembly assembly = System.Reflection.Assembly.GetExecutingAssembly();
 System.Reflection.AssemblyName assemblyName = assembly.GetName();
 Version version = assemblyName.Version;

Aby ustawić numer wersji, utwórz / edytuj plik AssemblyInfo.cs

 [assembly: AssemblyVersion("1.0.*")]
 [assembly: AssemblyFileVersion("1.0.*")]

Na marginesie, trzecia liczba to liczba dni od 2/1/2000, a czwarta liczba to połowa całkowitej liczby sekund w ciągu dnia. Więc jeśli kompilujesz o północy, powinna wynosić zero.

Kok
źródło
12

Istnieje rozszerzenie studio wizualne Wersje automatyczne Visual Studio które obsługuje Visual Studio (2012, 2013, 2015) 2017 i 2019.

Zrzuty ekranu wprowadź opis zdjęcia tutaj

wprowadź opis zdjęcia tutaj

Rahul
źródło
Więc go odinstalowałem i mogę powiedzieć jeszcze więcej ... modyfikuje oryginalny plik csproj. Myślę, że jest to bardzo problematyczne rozszerzenie.
Maxim,
2
@Maxim Wypróbuj najnowszą wersję, powinna działać na VS 2017
Rady
Doskonałe wykorzystanie. Działa dobrze dla mnie w vs2017. Dokumenty mogą być nieco jaśniejsze, ale zainstaluj je (za pośrednictwem strony), a następnie zainstaluj MSBuild za pośrednictwem Nuget, aplikuj do małego projektu i graj i buduj. Miły. Odpowiedź @ Booga nie zadziałała, chociaż powiedział dokładnie to, co próbowałem osiągnąć.
err1,
8

Ustawienie * w numerze wersji w AssemblyInfo lub we właściwościach projektu, jak opisano w innych postach, nie działa ze wszystkimi wersjami Visual Studio / .NET.

Afaik to nie działało w VS 2005 (ale w VS 2003 i VS 2008). W przypadku VS 2005 można użyć: Autoakrecji Numer wersji kompilacji i wersji Visual Studio 2005 w czasie kompilacji .

Należy jednak pamiętać, że automatyczna zmiana numeru wersji nie jest zalecana w przypadku zespołów o silnych nazwach. Powodem jest to, że wszystkie odniesienia do takiego zestawu należy aktualizować za każdym razem, gdy zespół, do którego następuje odwołanie, jest przebudowywany, ponieważ odwołania do zestawu o silnej nazwie są zawsze odniesieniem do określonej wersji zestawu. Same Microsoft zmieniają numer wersji zestawów .NET Framework tylko wtedy, gdy nastąpią zmiany w interfejsach. (NB: Wciąż szukam linku w MSDN, gdzie go przeczytałem).

Dirk Vollmar
źródło
Myślę, że dla każdej wersji VS można wstawić * tylko w polach Kompilacja lub Wersja. Właśnie wypróbowałem to za pomocą VS 2005 i działa dobrze. Nie jestem pewien, o czym mówi autor tego artykułu dotyczącego projektu kodu.
MusiGenesis,
Może wrócił z dodatkiem Service Pack, ale pamiętam, że nie działał, kiedy korzystałem z VS 2005.
Dirk Vollmar,
To nie działa z 2005, poszukaj dodatku service pack i zdam raport.
inspekcja
Być może MusiGenesis ma zainstalowany dodatek, który umożliwia automatyczne wersjonowanie.
Dirk Vollmar,
@divo: nie, jestem add-on-fobic. Mam tylko Visual Studio 2005 Professional SP1. Nigdy nie widziałem problemu z *, ale zwykle zwiększam ręcznie. Brzmi jak dziwny błąd.
MusiGenesis,
6

Aby uzyskać informacje o inkrementacji (DateTime) we właściwości AssemblyFileVersion, która ma tę zaletę, że nie przerywa żadnych zależności.


Opierając się na rozwiązaniu Boog (nie działało dla mnie, może z powodu VS2008?), Możesz użyć kombinacji zdarzenia przed kompilacją generującego plik, dodając ten plik (w tym jego właściwości wersji), a następnie korzystając ze sposobu odczytu te wartości ponownie. To jest..

Wydarzenie przed kompilacją:

echo [assembly:System.Reflection.AssemblyFileVersion("%date:~-4,4%.%date:~-7,2%%date:~-10,2%.%time:~0,2%%time:~3,2%.%time:~-5,2%")] > $(ProjectDir)Properties\VersionInfo.cs

Dołącz wynikowy plik VersionInfo.cs (podfolder Właściwości) do swojego projektu

Kod, aby odzyskać datę (lata do sekund):

var version = assembly.GetName().Version;
var fileVersionString = System.Diagnostics.FileVersionInfo.GetVersionInfo(assembly.Location).FileVersion;
Version fileVersion = new Version(fileVersionString);
var buildDateTime = new DateTime(fileVersion.Major, fileVersion.Minor/100, fileVersion.Minor%100, fileVersion.Build/100, fileVersion.Build%100, fileVersion.Revision);

Niezbyt wygodne .. nie wiem też, czy powoduje to wiele przebudowań wymuszonych (ponieważ plik zawsze się zmienia).

Możesz uczynić go mądrzejszym, na przykład, jeśli aktualizujesz plik VersionInfo.cs co kilka minut / godzin (używając pliku tymczasowego, a następnie kopiując / zastępując prawdziwy plik VersionInfo.cs, jeśli wykryje się wystarczająco dużą zmianę). Zrobiłem to raz całkiem pomyślnie.

Andreas Reiff
źródło
Działa idealnie. Jednak to wyrażenie regularne% data: ~ -4,4%.% Data: ~ -7,2 %% data: ~ -10,2%.% Czas: ~ 0,2 %% czas: ~ 3,2% .% time: ~ -5,2% "jest po prostu zbyt skomplikowane.
Cary
5

Ustaw numer wersji na „1.0. *”, A automatycznie wypełni dwa ostatnie numery datą (w dniach od pewnego momentu) i godziną (pół sekundy od północy)

James Curran
źródło
hej, gdybym to dobrze przeczytał na początku, uratowałbym się znacznie więcej. dzięki
inspekcja
4

Ciasto obsługuje łatanie plików AssemblyInfo. Z ciastem w rękach masz nieskończone możliwości implementacji automatycznego zwiększania wersji.

Prosty przykład wersji przyrostowej, takiej jak kompilator C #:

Setup(() =>
{
    // Executed BEFORE the first task.
    var datetimeNow = DateTime.Now;
    var daysPart = (datetimeNow - new DateTime(2000, 1, 1)).Days;
    var secondsPart = (long)datetimeNow.TimeOfDay.TotalSeconds/2;
    var assemblyInfo = new AssemblyInfoSettings
    {
        Version = "3.0.0.0",
        FileVersion = string.Format("3.0.{0}.{1}", daysPart, secondsPart)
    };
    CreateAssemblyInfo("MyProject/Properties/AssemblyInfo.cs", assemblyInfo);
});

Tutaj:

  • Wersja - to wersja zestawu. Najlepszą praktyką jest zablokowanie głównego numeru wersji i pozostawienie pozostałych zer (np. „1.0.0.0”).
  • FileVersion - to wersja pliku zespołu.

Pamiętaj, że możesz łatać nie tylko wersje, ale także wszystkie inne niezbędne informacje .

hal
źródło
3

Przejdź do projektu | Właściwości, a następnie Informacje o złożeniu, a następnie Wersja zestawu i wstaw * w ostatnim lub przedostatnim polu (nie można automatycznie zwiększać głównych lub mniejszych elementów).

MusiGenesis
źródło
2

Użyj zadania AssemblyInfo z Zadań społeczności MSBuild ( http://msbuildtasks.tigris.org/ ) i zintegruj je z plikiem .csproj / .vbproj.

Ma wiele opcji, w tym jedną, aby powiązać numer wersji z datą i godziną.

Zalecana.

devstuff
źródło
2

W tej chwili dla mojej aplikacji

string ver = Application.ProductVersion;

zwroty ver = 1.0.3251.27860

Wartość 3251 to liczba dni od 1/1/2000. Używam go do umieszczania daty utworzenia wersji na ekranie powitalnym mojej aplikacji. W kontaktach z użytkownikiem mogę zapytać o datę utworzenia, która jest łatwiejsza do przekazania niż jakaś długa liczba.

(Jestem jednoosobowym działem wspierającym małą firmę. Takie podejście może ci nie pomóc.)

SeaDrive
źródło
Twój numer szybko się wyczerpie. Użyłbym yyddd, który jest 2-cyfrowy rok i 3-cyfrowy dzień od początku roku, który wynosi maks. 365. przynajmniej twój program skompiluje się do roku 2065. wtedy będziesz na emeryturze i pozwól komuś innemu dowiedzieć się, jak on sobie z tym poradzi. biorąc pod uwagę, że wasz program jest jeszcze w tej dacie!
AaA
2

Zmiana AssemblyInfo działa w VS2012. Wydaje się dziwne, że nie ma już obsługi tego w Visual Studio, można by pomyśleć, że była to podstawowa część procesu kompilacji / wydania.

Maxcelcat
źródło
2

Jak uzyskać wersję {major}.{year}.1{date}.1{time}

Ten jest w pewnym sensie eksperymentalny, ale podoba mi się. Inspirowany przez Jeffa Atwooda @ CodingHorror ( link ).

Wynikowy numer wersji staje się 1.2016.10709.11641(czyli 2016-07-09 16:41), co pozwala

  • słaby mans zero padding (z głupimi prowadzącymi 1)
  • lokalny DateTime czytelny dla człowieka, osadzony w numerze wersji
  • pozostawiając wersję Major samą dla naprawdę poważnych przełomowych zmian.

Dodaj nowy element do projektu, wybierz Ogólne -> Szablon tekstowy, nazwij go jak CustomVersionNumberi (jeśli dotyczy) skomentuj AssemblyVersioni AssemblyFileVersionwe Properties/AssemblyInfo.cs.

Następnie, podczas zapisywania tego pliku lub budowania projektu, spowoduje to ponowne wygenerowanie .cspliku znajdującego się jako podelement w utworzonym .ttpliku.

<#@ template language="C#" #>
<#@ assembly name="System.Core" #>
<#@ import namespace="System.Linq" #>

//
// This code was generated by a tool. Any changes made manually will be lost
// the next time this code is regenerated.
//

using System.Reflection;

<#
    var date = DateTime.Now;
    int major = 1;
    int minor = date.Year;
    int build = 10000 + int.Parse(date.ToString("MMdd"));
    int revision = 10000 + int.Parse(date.ToString("HHmm"));
#>

[assembly: AssemblyVersion("<#= $"{major}.{minor}.{build}.{revision}" #>")]
[assembly: AssemblyFileVersion("<#= $"{major}.{minor}.{build}.{revision}" #>")]

źródło
Nie kompilujesz swojego programu co minutę ani nie wdrażasz więcej niż raz dziennie, więc technicznie część czasu niepotrzebnie zajmuje cenne informacje, użyłbym 1 i 2 dla ważniejszych drobnych i po prostu użyłbym 3 liczby dla daty yyddd (dwucyfrowy rok + ddd dzień od początku tego samego roku) i pozostaw czwarty dla przyrostowego numeru kompilacji.
AaA
2

Utworzyłem aplikację do automatycznego zwiększania wersji pliku.

  1. Pobierz aplikację
  2. dodaj następujący wiersz do wiersza poleceń zdarzenia przed kompilacją

    C: \ temp \ IncrementFileVersion.exe $ (SolutionDir) \ Properties \ AssemblyInfo.cs

  3. Zbuduj projekt

Aby to uprościć, aplikacja wyświetla komunikaty tylko w przypadku wystąpienia błędu, aby potwierdzić, że działa poprawnie, należy sprawdzić wersję pliku w „Informacje o montażu”

Uwaga: Będziesz musiał ponownie załadować rozwiązanie w Visual Studio dla przycisku „Informacje o złożeniu”, aby wypełnić pola, jednak plik wyjściowy będzie miał zaktualizowaną wersję.

Sugestie i prośby napisz do mnie na [email protected]

Telson Alva
źródło
2

W Visual Studio 2019

Nie wystarczyło mi dodanie

[assembly: AssemblyVersion("1.0.*")]

Podczas budowania rzuca mi ten błąd

Podany ciąg wersji nie jest zgodny z wymaganym formatem

Rozwiązanie

Format został ostatecznie przyjęty po ustawić Deterministicaby Falsewproject.csproj

<Deterministic>false</Deterministic>

Edytować:

Z jakiegoś powodu ustawienie DeterministicnaFalse zawiedli mojego pliku konfiguracyjnym ładuje go i zapisanie go w różnych miejscach.

Obejście:

Konfiguruję zdarzenie po kompilacji, aby zwiększyć numer wersji:

Skrypt wsadowy zdarzenia po kompilacji

To wywołuje skrypt PowerShell o nazwie autoincrement_version.ps1przekazywanie jako argument ścieżkiAssemblyInfo.cs

if $(ConfigurationName) == Release (
PowerShell -ExecutionPolicy RemoteSigned $(ProjectDir)autoincrement_version.ps1 '$(ProjectDir)My Project\AssemblyInfo.cs'
)

Skrypt Poweshell

Automatycznie zwiększa numer wersji za pomocą Regex

param( [string]$file );
  $regex_revision = '(?<=Version\("(?:\d+\.)+)(\d+)(?="\))'
  $found = (Get-Content $file) | Select-String -Pattern $regex_revision
  $revision = $found.matches[0].value
  $new_revision = [int]$revision + 1
  (Get-Content $file) -replace $regex_revision, $new_revision | Set-Content $file -Encoding UTF8
Madacol
źródło
1

Może do tego zadania możesz użyć takiego kodu:

    private bool IncreaseFileVersionBuild()
    {
        if (System.Diagnostics.Debugger.IsAttached)
        {
            try
            {
                var fi = new DirectoryInfo(AppDomain.CurrentDomain.BaseDirectory).Parent.Parent.GetDirectories("Properties")[0].GetFiles("AssemblyInfo.cs")[0];
                var ve = System.Diagnostics.FileVersionInfo.GetVersionInfo(System.Reflection.Assembly.GetExecutingAssembly().Location);
                string ol = ve.FileMajorPart.ToString() + "." + ve.FileMinorPart.ToString() + "." + ve.FileBuildPart.ToString() + "." + ve.FilePrivatePart.ToString();
                string ne = ve.FileMajorPart.ToString() + "." + ve.FileMinorPart.ToString() + "." + (ve.FileBuildPart + 1).ToString() + "." + ve.FilePrivatePart.ToString();
                System.IO.File.WriteAllText(fi.FullName, System.IO.File.ReadAllText(fi.FullName).Replace("[assembly: AssemblyFileVersion(\"" + ol + "\")]", "[assembly: AssemblyFileVersion(\"" + ne + "\")]"));
                return true;
            }
            catch
            {
                return false;
            }
        }
        return false;
    }

i wywołaj go z formularza ładowania.
Za pomocą tego kodu możesz zaktualizować dowolną część informacji o pliku w AssemblyInfo.cs (ale musisz użyć „standardowej” struktury katalogów).

Atiris
źródło
1

Używam tego podejścia https://stackoverflow.com/a/827209/3975786 , umieszczając szablon T4 w „Elementach rozwiązania” i używam go z „Dodaj jako łącze” w ramach każdego projektu.

Mcandal
źródło
1

Być może jest już za późno, aby odpowiedzieć tutaj, ale mam nadzieję, że rozwiąże czyjś gorączkowy problem.

Automatyczny sposób zmiany wersji zestawu wszystkich projektów za pomocą skryptu PowerShell. Ten artykuł rozwiąże wiele twoich problemów.

Khawaja Asim
źródło
Jedynym problemem związanym z PS jest to, że reaguje wolno i wymaga konfiguracji, aby mógł działać. Wybrałbym mały plik wykonywalny, plik tt4 lub nawet wbudowany kod, który myślę, że każdy programista może napisać w jeden sposób.
AaA
0

Za każdym razem, gdy robię kompilację, automatycznie zwiększa najmniej znaczącą cyfrę.

Nie mam pojęcia, jak zaktualizować pozostałe, ale przynajmniej powinieneś już to zobaczyć ...

Brian Knoblauch
źródło
1
VS odpowiada za zwiększenie ostatniego numeru, który jest zwykle numerem kompilacji. Wszystko inne (tj. Liczby przed tym) zależy od Ciebie, ponieważ reprezentują wersję Twojej aplikacji.
Огњен Шобајић
1
Odpowiedź: Nie do końca dobrze. Schemat numerowania firmy Microsoft to wersja główna.nieważna.budowa, np. 1.0.4.7. Jeśli ustawisz wersję zestawu na coś takiego jak „1.0. *”, Wówczas VS ustawi dla ciebie numery kompilacji i wersji. W takim przypadku kompilacja będzie się zwiększać codziennie, a korekta będzie liczbą sekund od północy podzieloną przez 2.
Simon Tewsi
0

Dla każdego używającego Tortoise Subversion możesz powiązać jeden ze swoich numerów wersji z numerem wersji subversion twojego kodu źródłowego. Uważam to za bardzo przydatne (Audytorzy też to lubią!). Robisz to, wywołując narzędzie WCREV we wcześniejszej kompilacji i generując plik AssemblyInfo.cs z szablonu.

Jeśli szablon nazywa się AssemblyInfo.wcrev i znajduje się w normalnym katalogu AssemblyInfo.cs, a żółw znajduje się w domyślnym katalogu instalacyjnym, wówczas polecenie Pre-Build wygląda następująco (NB Wszystkie w jednym wierszu):

"C:\Program Files\TortoiseSVN\bin\SubWCRev.exe" "$(ProjectDir)." "$(ProjectDir)Properties\AssemblyInfo.wcrev"  "$(ProjectDir)Properties\AssemblyInfo.cs"

Plik szablonu zawierałby łańcuch podstawiania tokena wcrev: $ WCREV $
np

[assembly: AssemblyFileVersion("1.0.0.$WCREV$")]

Uwaga:
Ponieważ plik AssemblyInfo.cs jest teraz generowany, nie chcesz, aby kontrolowano jego wersję.

John Denniston
źródło