Odpowiednik AssemblyInfo w dotnet core / csproj


236

Ponieważ rdzeń dotnet wrócił do tego .csprojformatu, pojawiło się nowe automatyczne generowanie, MyProject.AssemblyInfo.csktóre zawiera między innymi.

[assembly: AssemblyCompany("MyProject")]
[assembly: AssemblyVersion("1.0.0.0")]

Pamiętaj, że jest on automatycznie regenerowany przy każdej kompilacji. Wcześniej plik został znaleziony w katalogu / obj /, teraz wydaje się, że jest tylko w pamięci, ponieważ pliku nie można znaleźć na dysku, a kliknięcie komunikatu o błędzie nie powoduje otwarcia żadnego pliku.

Oto komunikat o błędzie: wprowadź opis zdjęcia tutaj

Ponieważ są tam zdefiniowane, nie mogę ich zdefiniować w klasyce AssemblyInfo.cs.

Gdzie / jak mogę zdefiniować firmę i wersję projektu?


5
Pamiętaj, że nie jest to ściśle związane z rdzeniem dotnet. Jest to raczej związane z nowym formatem opartym na .csproj. Użycie tego nowego formatu .csproj do celowania w starą platformę .NET Framework, na przykład net461
Jim Aho,

Odpowiedzi:


334

Jak już zauważyłeś, możesz kontrolować większość tych ustawień w .csproj.

Jeśli wolisz zachować je w pliku AssemblyInfo.cs, możesz wyłączyć automatycznie generowane atrybuty złożenia.

<PropertyGroup>
   <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup> 

Jeśli chcesz zobaczyć, co się dzieje pod maską, sprawdź Microsoft.NET.GenerateAssemblyInfo.targets wewnątrz Microsoft.NET.Sdk.


41
Cieszę się, że mogę to wyłączyć. Nazywaj mnie staromodnym, ale wolę stary, dobry plik AssemblyInfo.cs niż automatycznie generowane pliki .netcore. Poza tym używam zewnętrznego oprzyrządowania do zarządzania moimi wersjami i zawartością innych wpisów AssembyInfo. Próbowałem użyć niestandardowego celu, aby moje właściwości nie były widoczne w samym projekcie, ale przez pewien czas dusiłem się.
Ivaylo Slavov

1
To samo tutaj. Dzięki nowemu systemowi opartemu na csproj nie mogłem korzystać ze starego narzędzia. Dzięki tej właściwości mogę teraz wrócić, co uwielbiam!
Ustrukturyzowano

5
NuGet nie czyta pliku AssemblyInfo.cs. Nadal musisz użyć właściwości MSBuild, aby zdefiniować wersję pakietu NuGet.
natemcmaster

6
kiedy plik jest generowany automatycznie, jak ustawić atrybut InternalsVisibleTo w nowym formacie csproj?
Shubhan

8
@Shubhan nie jest to jeden z automatycznie generowanych atrybutów. Utwórz pusty plik .cs gdzieś w swoim projekcie i dodaj do niego kod InternalsVisibleTo
natemcmaster

128

Te ustawienia zostały przeniesione do pliku .csproj.

Domyślnie nie są wyświetlane, ale możesz je odkryć w programie Visual Studio 2017 na Packagekarcie właściwości projektu .

Właściwości projektu, zakładka Pakiet

Po zapisaniu wartości te można znaleźć w MyProject.csproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net461</TargetFramework>
    <Version>1.2.3.4</Version>
    <Authors>Author 1</Authors>
    <Company>Company XYZ</Company>
    <Product>Product 2</Product>
    <PackageId>MyApp</PackageId>
    <AssemblyVersion>2.0.0.0</AssemblyVersion>
    <FileVersion>3.0.0.0</FileVersion>
    <NeutralLanguage>en</NeutralLanguage>
    <Description>Description here</Description>
    <Copyright>Copyright</Copyright>
    <PackageLicenseUrl>License URL</PackageLicenseUrl>
    <PackageProjectUrl>Project URL</PackageProjectUrl>
    <PackageIconUrl>Icon URL</PackageIconUrl>
    <RepositoryUrl>Repo URL</RepositoryUrl>
    <RepositoryType>Repo type</RepositoryType>
    <PackageTags>Tags</PackageTags>
    <PackageReleaseNotes>Release</PackageReleaseNotes>
  </PropertyGroup>

Na karcie informacji o właściwościach eksploratora plików FileVersionjest wyświetlany jako „Wersja pliku” i Version„Wersja produktu”


1
Ustawienia we właściwościach projektu wydają się brakować, jeśli moim typem projektu jest Class Library (.NET Standard). Czy masz pojęcie dlaczego? Używam wersji 15.1, wydanie 26403.7, wydanie społecznościowe.
ventiseis

2
Korzystam z biblioteki klas (.NET Standard) i widzę to w zakładce Pakiety. Widzisz to tam? Gdy „zapiszesz” coś innego niż domyślne, pojawi się w csproj.
tofutim

3
Jak korzystać z symboli wieloznacznych, takich jak 1.0. *. * Podczas korzystania z karty pakietów?
Soenhay

@Soenhay, symbole wieloznaczne nie mają większego sensu przy definiowaniu wersji pakietu, tylko podczas jego konsumpcji.
Paul Hatcher

@ Soenhay rozumiem, że nie możesz, chyba że użyjesz podobnej funkcji w narzędziach stron trzecich.
hultqvist

115

Robię następujące dla moich projektów .NET Standard 2.0.

Utwórz Directory.Build.propsplik (np. W katalogu głównym repozytorium) i przenieś właściwości do udostępnienia z .csprojpliku do tego pliku.

MSBuild pobierze go automatycznie i zastosuje do automatycznie wygenerowanego AssemblyInfo.cs.

Są one również stosowane do pakietu nuget podczas budowania go za dotnet packpomocą interfejsu użytkownika lub za pośrednictwem interfejsu użytkownika w programie Visual Studio 2017.

Zobacz https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build


12
To powinno zyskać więcej głosów pozytywnych, miło zezwolić na automatyczne generowanie, ale nadal dzielić się niektórymi rzeczami w ramach jednego rozwiązania
Dan

@ Dan zgodził się, to jest tak daleko poniżej innych odpowiedzi, że podejrzewam, że większość ludzi po prostu tego nie czyta.
Lunyx

1
@ Justin, nie zobaczysz ich w plikach projektu; są one stosowane do powstałych zbudowanych zespołów.
pfx

1
Co z tymi z nas, którzy nie używają msbuild?
Joe Phillips

1
To była świetna odpowiedź. Dziękuję Ci. Użyliśmy go w naszym dużym rozwiązaniu, które produkuje niektóre pakiety NuGet, i jest to świetna alternatywa dla starych informacji o montażu dla nowych projektów w stylu sdk
David Anderson,

57

Zawsze możesz dodać własny plik AssemblyInfo.cs , który jest przydatny InternalsVisibleToAttribute, CLSCompliantAttributei inne, które nie są generowane automatycznie.

Dodawanie AssemblyInfo.cs do projektu

  1. W Solution Explorer kliknij prawym przyciskiem myszy <project name> > Add > New Folder.

Dodaj nowy folder

  1. Nazwij folder „Właściwości”.

Nazwa folderu Właściwości

  1. Kliknij prawym przyciskiem myszy folder „Właściwości” i kliknij Add > New Item....

Dodaj nową pozycję

  1. Wybierz „Class” i nazwij go „AssemblyInfo.cs”.

Plik nazwy AssemblyInfo.cs

Pomijanie automatycznie generowanych atrybutów

Jeśli chcesz przenieść atrybuty z powrotem do pliku AssemblyInfo.cs zamiast generować je automatycznie, możesz ukryć je w MSBuild, jak wskazał natemcmaster w swojej odpowiedzi .


1
Dzięki NightOwl888, to jest odpowiedź, której szukam.
Juniuz

3
Nie chciałbym zakładać, że każdy ma teraz Visual Studio, są też inne edytory, które mogłyby utrudnić naśladowanie niektórych odpowiedzi (np. Robię to na Macu / Mono używając Jetbrains Rider)
PandaWood

Czasami nowi potencjalni klienci firmy Microsoft powinni rozważyć zachowanie tego, co działa dobrze w pliku AssemblyInfo.cs, aby zautomatyzowane kompilacje mogły nadal działać w celu modyfikacji numerów kompilacji.
justdan23

6

Dodając do odpowiedzi NightOwl888, możesz pójść o krok dalej i dodać AssemblyInfoklasę, a nie zwykłą klasę:

wprowadź opis zdjęcia tutaj


5
Nie ma „pliku informacji o złożeniu”, gdy otwieram to okno dialogowe w VS2019 dla projektu Netstandard 1.1.
SwissCoder,

Dziękujemy za opublikowanie tego! Używam .NET Core 3.1 i właśnie tam był! Dodaje wszystkie kluczowe części domyślne.
justdan23

6

Chcę rozszerzyć ten temat / odpowiedzi na następujące. Jak ktoś wspomniał, to automatycznie wygenerowane AssemblyInfo może stanowić przeszkodę dla zewnętrznych narzędzi. W moim przypadku przy użyciu FinalBuilder miałem problem, że AssemblyInfo nie był aktualizowany przez akcję kompilacji. Najwyraźniej FinalBuilder polega na ~projpliku, aby znaleźć lokalizację AssemblyInfo . Myślałem, że szukał gdziekolwiek w folderze projektu. Nie. Więc to zmieniam

<PropertyGroup>
   <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup> 

wykonał tylko połowę pracy, pozwalał na niestandardowe informacje o montażu, jeśli został zbudowany przez VS IDE / MS Build. Ale potrzebowałem też FinalBuilder, aby to zrobić bez ręcznych manipulacji plikiem informacji o złożeniu. Musiałem zadowolić wszystkie programy, MSBuild / VS i FinalBuilder.

Rozwiązałem to, dodając wpis do istniejącego ItemGroup

<ItemGroup>
   <Compile Remove="Common\**" />
   <Content Remove="Common\**" />
   <EmbeddedResource Remove="Common\**" />
   <None Remove="Common\**" />
   <!-- new added item -->
   <None Include="Properties\AssemblyInfo.cs" />
</ItemGroup>

Teraz, mając ten element, FinalBuilder znajduje lokalizację AssemblyInfo i modyfikuje plik. Chociaż akcja Nonepozwala MSBuild / DevEnv zignorować ten wpis i nie będzie już zgłaszać błędu na podstawie Compileakcji, która zwykle pochodzi z pozycji Informacje o złożeniu w projplikach.

C: \ Program Files \ dotnet \ sdk \ 2.0.2 \ Sdks \ Microsoft.NET.Sdk \ build \ Microsoft.NET.Sdk.DefaultItems.targets (263,5): błąd: uwzględniono zduplikowane elementy „Kompiluj”. Zestaw .NET SDK domyślnie zawiera elementy „Kompiluj” z katalogu projektu. Możesz usunąć te elementy z pliku projektu lub ustawić właściwość „EnableDefaultCompileItems” na „false”, jeśli chcesz jawnie dołączyć je do pliku projektu. Aby uzyskać więcej informacji, zobacz https://aka.ms/sdkimplicititems . Zduplikowane elementy to: „AssemblyInfo.cs”

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.