Jeden wspólny AssemblyInfo dla całej solucji

Tak wygłada AssemblyInfo.cs stworzony przez Visual Studio w nowym projekcie:

using System.Reflection;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;

// General Information about an assembly is controlled through the following 
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
[assembly: AssemblyTitle("YourProjectName")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("YourCompanyName")]
[assembly: AssemblyProduct("YourProjectName")]
[assembly: AssemblyCopyright("Copyright © YourCompanyName 2017")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]

// Setting ComVisible to false makes the types in this assembly not visible 
// to COM components.  If you need to access a type in this assembly from 
// COM, set the ComVisible attribute to true on that type.
[assembly: ComVisible(false)]

// The following GUID is for the ID of the typelib if this project is exposed to COM
[assembly: Guid("7a08ceec-6dc3-45a1-8c2d-338ab1bac448")]

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
// 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")]

Ja tu zawsze widzę dużo śmieci. Przy kilkunastu/kilkudziesięciu projektach tych śmiecie jest liniowo więcej. Może czasem niektóre z nich w Waszym kontekście są potrzebne. Moje doświadczenia są jednak takie, że ten plik mógłby wyglądać:

using System.Reflection;

[assembly: AssemblyVersion("1.0.0")]

bo jedyne co naprawdę mnie interesuje to podbijanie wersji. I od tej wersji się ostatnio zaczęło, bo trzeba to podbijać i najlepiej wszędzie na raz. Można to zrobić skryptem buildującym (np u mnie obecnie PowerShell). A można skorzystać z współdzielenia jednego AssemblyInfo między wszystkimi projektami.

Źródło: Shared AssemblyInfo for uniform versioning across the solution

Skorzystałem z ręcznego dodawania linków, które jest opisane w drugiej odpowiedzi do powyższego pytania, a wygląda:

  1. Right click on the project, in which you wish to add the Shared assembly file, and select Add -> Existing Item…
  2. Select the file “SharedAssemblyInfo.cs” from the solution folder.
  3. Instead of Add, click on the the arrow next to Add and click “Add as Link”
  4. Drag down the added linked file alongside AssemblyInfo.cs in the same folder.
  5. Repeat steps 1 – 4 for all projects for which you wish to add shared assembly file.

Wersję więc podbijam ręcznie, nie potrzebuję żadnych skryptów. Plik SharedAssemblyInfo.cs wrzuciłem na tym samym poziomie co solucja i dodałem do folderu „Solution Items” w solucji.

shared assemblyinfo in solution explorer

Oprócz tego czasem pojawia się zwykły plik AssemblyInfo.cs per projekt. Jedyną rzeczą, która w nim jest to attrybut InternalsVisibleTo:

using System.Runtime.CompilerServices;

[assembly: InternalsVisibleTo("YourCompany.YourProject.Core.Tests")
Reklamy
Ten wpis został opublikowany w kategorii DevOps i oznaczony tagami , , , , , . Dodaj zakładkę do bezpośredniego odnośnika.

7 odpowiedzi na „Jeden wspólny AssemblyInfo dla całej solucji

  1. Łukasz K. pisze:

    Świetna sprawa, dobry wpis.

  2. Pingback: dotnetomaniak.pl

  3. Lech pisze:

    Opcja ciekawa, ale zastanawiam się czy ręczne podbijanie wersji może się sprawdzać gdzieś indziej niż tylko w jednoosobowym zespole i w pracy nad jakimś OSS? Bo nawet w kilkuosobowym projekcie wydaje mi się, że byłoby to zbyt uciążliwe i podatne na pomyłki (sczególnie przy rozbudowanej sieci branchy w git). Co sądzisz? 🙂

    • @Lech
      Jeśli chodzi o rozbudowaną sieć branchy to nie mam tego problemu. Korzystam z
      https://trunkbaseddevelopment.com. I polecam.

      A co jest złego w ręcznym podbijaniu jeśli jest tylko jeden plik? Muszę sam podjąć decyzję czy podbijam Major, Minor czy Build i to jest raczej rzadkie.

      Można zrobić 2 skrypty bump-minor-number.ps1 i bump-build-number.ps1 (major jest bardzo rzadkie) i mieć większą pewność. Będzie to lepsze, zgoda. – Dla prostoty i zaoszczędzenia czasu zostawiłem jak napisałem, zespół ma 6 osób, z tego paczki wystawiać będzie powiedzmy 3.

  4. Tomasz Oryński pisze:

    Stosuje od paru lat. Sprawdza się swietnie przy CI – na maszynie buildującej można ten plik stworzyć nawet od zera.
    Potem miałem małą skuchę przy .net core, bo tam jest domyslnie generowane z właściwości projektu (w tle generowany plik *.cs), ale na szczęście daje się wyłączyć i metadane trzymać we własnym pliku *.cs.

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj / Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj / Zmień )

Zdjęcie na Google+

Komentujesz korzystając z konta Google+. Wyloguj / Zmień )

Connecting to %s