Za każdym razem, gdy pojawia się nowe wydanie (choćby tylko wstępne, na użytek wewnętrzny a nie już dla klienta), trzeba wejść w Visual Studio we właściwości projektu -> assembly information -> podbić Assembly version oraz File version według ustalonego przez szefa schematu wersjonowania.
Uporczywie o tym zapominam i już dwa razy zdarzyło mi się wprowadzić w gicie tag z nową wersją, tyle że wersja według tagu w gicie nie odpowiadała wersji assembly.
Ponieważ decyzją szefa aplikacja (choć siedzi w jednej solucji VS) jest podzielona na mnóstwo projektów i bibliotek, to każda nowa wersja = liczne ręczne podbijanie wersji rozmaitych assemblies. Zaczyna mnie to irytować.
Z racji na poprzedni wątek, gdzie tłukliście mi do głowy, że mam przestać wszystko robić ręcznie i stosować odnośne biblioteki - czy jest jakieś narzędzie, które automatyzuje takie zadania?
Tak wiem - out of the box mamy automatyczne podbijanie build number. Tyle że:
- Nie rozumiem sensu tej funkcjonalności - po co wiedzieć, ile razy projekt był kompilowany? To już numer commitu do gita wydaje się bardziej przydatny
- Np. załóżmy, że mamy build number 123, teraz Iksiński robi swojego brancha i wprowadza poprawki - build number 124 - ale zanim Iksiński spushuje to, Igrekowicz także robi brancha i wprowadza inne poprawki, więc mamy dwie zupełnie różne wersje aplikacji o build number 124! - w konsekwencji nie wiem, jak build number ma być przydatny przy wersjonowaniu - ale za to numery commitów Iksińskiego i Igrekowicza będą się różnić, więc to będzie już przydatne
- Załóżmy dalej, że Igrekowicz kompiluje apke dwa razy, zanim zrobi commit (build 124 - nie, jednak coś nie tak - build 125 - commit). Jakie ma znaczenie wersja 124? Przecież ona nawet nie zostala zcommitowana, poszła sobie w siną dal. Znaczenie może miec co najwyżej wersja 125, ale ona i tak jest opisana numerem commitu do gita
- I tak decyzją szefa build number nie jest używany, mamy tylko major.minor, przy czym minor ma być inkrementowane przy każdym nowym wydaniu, nawet jeśli to tylko wydanie testowe na uzytek wewnętrzny
To, co byłoby przydatne tutaj, to chyba raczej coś takiego: skrypt "wydaj nową wersję", który przyjmuje wersję jako parametr, ustawia wszystkie liczne AssemblyInfo.cs na tę wersję, robi commita i otagowuje tego commita tagiem z tą wersją. Taki skrypcik byłby prosty do napisania, ale pewnie znowu byłoby to samo, co w wątku, który zalinkowałem wyżej - że niesłusznie wynajduję koło na nowo i samodzielnie rozwiązuję problemy, na które ktoś już napisał bibliotekę.
Jest jakieś narzędzie automatyzujące to? Przede wszystkim: Pozwalające za jednym zamachem ustawić wersję we wszystkich plikach AssemblyInfo.cs w danym projekcie na żądaną?
C# 
Microsoft Visual Studio 
dotnet buildalbodotnet publishto możesz nadpisać rzeczy z csproj - np. w Azure DevOps mam skrypt, który robidotnet build --configuration $(buildConfiguration) /p:Version=$(GitVersion.SemVer) /p:InformationalVersion=$(GitVersion.FullSemVer)i podstawia odpowiednie zmienne.