Spędziłem większą część kilku godzin, próbując znaleźć sposób na automatyczne zwiększanie wersji w .NETCoreApp 1.1 (Visual Studio 2017).
Wiem, że plik AssemblyInfo.cs jest tworzony dynamicznie w folderze: obj/Debug/netcoreapp1.1/
Nie akceptuje starej metody:
[assembly: System.Reflection.AssemblyFileVersionAttribute("1.0.0.*")]
Jeśli ustawię projekt na pakiet, mogę ustawić tam wersje, ale wydaje się, że jest to używane do budowania pliku AssemblyInfo.cs.
Moje pytanie brzmi: czy ktoś wymyślił, jak kontrolować wersję w projektach .NET Core (lub .NETStandard).
/p:
flagędotnet msbuild
w swoim skrypcie kompilacji i ustawić wersję, firmę, prawa autorskie ... wszystkie te dobre rzeczy.<Deterministic>False</Deterministic>
w csproj, aby go używać. (lub użyj innej logiki MSbuild do obliczenia<VersionPrefix>
/<Version>
)Odpowiedzi:
Szukałem programu do zwiększania wersji aplikacji Net Core w VS2017 przy użyciu formatu konfiguracji csproj.
Znalazłem projekt o nazwie dotnet bump, który działał dla formatu project.json, ale miał problem ze znalezieniem rozwiązania dla formatu .csproj. Twórca dotnet bump faktycznie wymyślił rozwiązanie dla formatu .csproj i nazywa się MSBump.
Istnieje projekt na GitHub dla tego pod adresem:
https://github.com/BalassaMarton/MSBump
gdzie możesz zobaczyć kod i jego dostępność również na Nuget. Po prostu wyszukaj MSBump na Nuget.
źródło
Dodaj
<Deterministic>False</Deterministic>
wewnątrz<PropertyGroup>
sekcji .csprojObejście umożliwiające działanie AssemblyVersion * opisano w „Mylący komunikat o błędzie dla symbolu wieloznacznego w [AssemblyVersion] w .Net Core # 22660”
Powody, dla których programiści .Net Core uważają, że kompilacje deterministyczne są korzystne, opisane w http://blog.paranoidcoding.com/2016/04/05/deterministic-builds-in-roslyn.html i kompilatorach powinny być deterministyczne: te same dane wejściowe generują te same wyniki # 372
Jeśli jednak używasz TeamCity, TFS lub innego narzędzia CI / CD, prawdopodobnie lepiej jest kontrolować i zwiększać numer wersji i przekazywać go jako parametr do kompilacji (jak sugerowano w innych odpowiedziach), np.
Numer pakietu dla pakietów NuGet
źródło
Jeśli używasz programu Visual Studio Team Services / TFS lub innego procesu kompilacji CI, który ma wbudowane przechowywanie wersji, możesz użyć
Condition
atrybutu msbuild , na przykład:Dzięki temu kompilator .NET Core ma użyć dowolnej
BUILD_BUILDNUMBER
zmiennej środowiskowej, jeśli jest obecna, lub cofnąć się,0.0.1-local
jeśli tworzysz kompilację na komputerze lokalnym.źródło
Wymyśliłem rozwiązanie, które działało prawie tak samo, jak stary atrybut AssemblyVersion z gwiazdką (*) - AssemblyVersion („1.0. ”) *
Wartości dla AssemblyVersion i AssemblyFileVersion znajdują się w pliku .csproj projektu MSBuild (nie w AssemblyInfo.cs ) jako właściwość FileVersion (generuje AssemblyFileVersionAttribute ) i AssemblyVersion (generuje AssemblyVersionAttribute ). W procesie MSBuild używamy naszego niestandardowego zadania MSBuild do generowania numerów wersji, a następnie zastępujemy wartości tych właściwości FileVersion i AssemblyVersion nowymi wartościami z zadania.
Więc najpierw tworzymy nasze niestandardowe zadanie MSBuild GetCurrentBuildVersion :
Zadanie klasa dziedziczy z Microsoft.Build.Utilities.Task klasy z Microsoft.Build.Utilities.Core pakietu Nuget. Pobiera właściwość BaseVersion (opcjonalna) na wejściu i zwraca wygenerowaną wersję we właściwości wyjściowej wersji. Logika uzyskiwania numerów wersji jest taka sama jak w przypadku automatycznego sprawdzania wersji .NET (numer kompilacji to liczba dni od 1 stycznia 2000 r., A wersja to pół sekundy od północy).
Aby zbudować to zadanie MSBuild, używamy typu projektu biblioteki klas .NET Standard 1.3 z tą klasą.
Plik .csproj może wyglądać następująco:
Ten projekt zadania jest również dostępny w moim holajan / DC.Build.Tasks w serwisie GitHub
Teraz konfigurujemy program MSBuild do korzystania z tego zadania i ustawiamy właściwości FileVersion i AssemblyVersion . W pliku .csproj wygląda to tak:
Ważne rzeczy tutaj:
Zaletą tego rozwiązania jest to, że działa nie tylko z kompilacji na serwerze kompilacji, ale także w kompilacjach ręcznych z kompilacji dotnet lub programu Visual Studio.
źródło
DateTime.UtcNow
zamiast in, zwłaszcza jeśli kod jest wykonywany na automatach do kompilacji. Mogą działać o 2 lub 3 nad ranem, kiedy komputer przełącza się na / z czasu letniego. W tym scenariuszu możesz cofać się pod względem wersji. Trzeba przyznać, że jest to sprawa narożna i przyznaję też, że jestem wybredna. :-) Ponadto problem znika również, jeśli skonfigurujesz tę samą strefę czasową na wszystkich maszynach do budowania i nie dostosujesz się do czasu letniego.DateTime.Now
GetCurrentBuildVersionString()
DateTime.Now
Można użyć funkcji właściwości programu MSBuild, aby ustawić sufiks wersji na podstawie bieżącej daty:
Spowoduje to wyświetlenie pakietu o nazwie takiej jak: NazwaPakietu.1.0.0-pre20180807-1711.nupkg .
Więcej szczegółów na temat funkcji właściwości MSBuild: https://docs.microsoft.com/en-us/visualstudio/msbuild/property-functions
Version
Powstaje z połączeniaVersionPrefix
iVersionSuffix
, lub jeśliVersionSuffix
jest pusty,VersionPrefix
tylko.źródło
Przyjąłem powyższą odpowiedź, ponieważ @Gigi jest poprawne (na razie), ale byłem zirytowany i wymyśliłem następujące skrypty PowerShell.
Najpierw mam skrypt w folderze mojego rozwiązania (UpdateBuildVersion.ps1):
Dodałem to do pliku csproj:
Nawet jeśli ustawiono go jako zdarzenie PreBuildEvent, faktem jest, że numery wersji nie są aktualizowane, dopóki plik nie zostanie załadowany do pamięci, więc numer wersji nie będzie widoczny do następnej kompilacji. W rzeczywistości możesz zmienić to na PostBuildEvent i miałoby to ten sam efekt.
Stworzyłem również dwa następujące skrypty: (UpdateMinorVersion.ps1)
(UpdateMajorVersion.ps1)
źródło
dotnet build /p:AssemblyVersion=1.2.3.4
Odpowiadałem na pytanie: „czy ktoś wymyślił, jak kontrolować wersję w projektach .NET Core (lub .NETStandard)”. Znalazłem to pytanie, próbując rozwiązać ten problem w kontekście kompilacji CI. Chciałem ustawić wersję zestawu na numer kompilacji CI.
źródło
Te wartości są teraz ustawione w
.csproj
pliku:Są to te same wartości, które widzisz, jeśli przejdziesz na kartę Pakiet w ustawieniach projektu. Chociaż nie wydaje mi się, abyś mógł użyć funkcji
*
autoinkrementacji wersji, to co możesz zrobić, to wprowadzić etap przetwarzania końcowego, który zastępuje wersje za Ciebie (np. Jako część ciągłej integracji).źródło
Zrobiłem proste narzędzie CLI do ustawiania .csproj NET podstawowych ciągów wersja tutaj . Możesz połączyć to z narzędziami takimi jak GitVersion do automatycznego przełączania wersji podczas kompilacji CI, jeśli tego szukasz.
źródło
Aby umożliwić wersjonowanie twojego .Net Core / .Net Niezależnie od projektu opartego na twojej konfiguracji GIT, używając tagów / opisz funkcjonalność GIT.
Używam pliku Prebuild.targets.xml, który znajduje się w folderze głównym projektu i jest zawarty w pliku csproj, na przykład:
Użyj tagu „GenerateAssembyInfo”, aby wyłączyć automatyczne generowanie informacji o zestawie.
Następnie plik Prebuild.targets.xml wygeneruje plik CommonAssemblyInfo.cs, w którym możesz dołączyć żądane znaczniki wersji na podstawie wersji GIT
UWAGA: Znalazłem plik Prebuilds.targets.xml gdzie indziej, więc nie zawracałem sobie głowy czyszczeniem).
Plik Prebuild.targets.xml:
EDYCJA: Jeśli tworzysz przy użyciu programu MSBUILD, plik
Może sprawić ci kłopoty, użyj
zamiast
źródło
Możesz wykonać poniższe czynności w pliku csproj. Nie rozgryzłem matematyki. Znalazłem to gdzieś indziej na stackoverflow. Ale to działa i da ci coś podobnego do 1.0. * Dla wersji.
źródło
Rozszerzenie Automatic Versions dla programu Visual Studio obsługuje teraz funkcję autoinkrementacji .Net Core i .Net Standard w prostym interfejsie użytkownika.
https://marketplace.visualstudio.com/items?itemName=PrecisionInfinity.AutomaticVersions
źródło
Dziękuję @joelsand za wskazanie mi właściwego kierunku.
Musiałem nieco zmienić jego odpowiedź, ponieważ po uruchomieniu kompilacji DevOps dostałem następujący wyjątek
Musiałem dodać $ (BUILD_BUILDNUMBER) na końcu sekcji major.minor.build. Aby usunąć duplikaty aktualnej wersji, używam również prefiksu wersji:
źródło
Możemy użyć specjalnego parametru dla
dotnet publish -- version-suffix 1.2.3
Wersja pliku:
Wersja:
https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-publish?tabs=netcore21
źródło
Myślę, że ta odpowiedź od @joelsand jest poprawną odpowiedzią na ustawienie numeru wersji rdzenia dotnet działającego na VSTS
Aby dodać więcej informacji do tej odpowiedzi,
BUILD_BUILDNUMBER
jest właściwie predefiniowaną zmienną .Okazuje się, że istnieją 2 wersje predefiniowanej zmiennej.
Jeden to build.xxxx, drugi to BUILD_XXXX.
Możesz używać tylko
Environment Variable Name
w cproj.źródło
build.xxxx
używany w interfejsie użytkownika do odwoływania się w potoku iBUILD_XXXX
ma tę samą wartość, ale z nieznacznie zmodyfikowaną składnią wymaganą do odwoływania się do zmiennej w PS?