Czy potrzebuję AssemblyInfo podczas pracy z .NET Core?

Question

Poprzednio plik AssemblyInfo.cs był automatycznie tworzony przez program Visual Studio w celu zawarcia atrybutów obejmujących cały zespół, takich jak AssemblyVersion, AssemblyName i tak dalej.

W rdzeniu .NET Core i ASP.NET, project.json jest odpowiedzialny za przechowywanie większości tych informacji.

Pytanie brzmi: czy muszę już oznaczać moje zespoły tymi atrybutami? Jakich pułapek można użyć, jeśli nie zaznaczę zespołu za pomocą tych atrybutów?

Answer 1

project.json zastąpił AssemblyInfo.

AssemblyVersionAttribute zastępuje version własności

version 
Type: String 
The Semver version of the project, also used for the NuGet package. 

AssemblyNameAttrinbute jest teraz własnością

name 
Type: String 
The name of the project, used for the assembly name as well as the name of the package. The top level folder name is used if this property is not specified. 

i tak dalej

---

Aktualizacjiname : Podobnie jak w przypadku ogłaszania narzędzia .NET Core Tools MSBuild, .csproj jest zastępowany project.json, ale ponownie znajduje się plik AssemblyInfo.cs, ale większość ustawień została przeniesiona bezpośrednio do .csproj. Zobacz podobne pytanie SO Więcej szczegółów: Equivalent to AssemblyInfo in dotnet core/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> 

Answer 2

project.json nie jest bezpośrednim zamiennikiem AssemblyInfo.cs, więc nadal istnieje potrzeba jeśli chcesz zdefiniować pewne wartości, które nie mogą zapewnić w project.json.

z emisji https://github.com/aspnet/dnx/issues/2715 można zobaczyć, że na początku pewne parametry, jak title, description, copyright itp gdzie podjęte, aby wypełnić pola dla generowanych pakietów Nuget. W kwestii 2715 narodził się pomysł, że wartości te mogą "wpłynąć do Zgromadzenia". Aby nie konfigurować tych pól w dwóch różnych miejscach. Więc jeśli nie chcesz konfigurować więcej niż te parametry, AssemblyInfo.cs nie jest potrzebny.

Istnieją inne pola, takie jak [InternalsVisibleTo], których nie można skonfigurować w project.json. Są więc przypadki, w których wciąż istnieje potrzeba zdefiniowania jednego.