Do I need AssemblyInfo while working with .NET Core?

Question

Previously, AssemblyInfo.cs file was autocreated by Visual Studio to contain assembly-wide attributes, like AssemblyVersion, AssemblyName and so on.

In .NET Core and ASP.NET Core, project.json is responsible for holding most of that information.

So the question is: do I need to mark my assemblies with that attributes anymore? What traps can I get in if I will not mark assembly with that attributes?

Could you be more specific which attributes you miss and what you are afraid of? — Danny van der Kraan, Aug 26 '16 at 10:21
I'm finding attributes redundant actually: `AssemblyVersion`(`version`), `AssemblyTitle`(`title`), `AssemblyDescription`(`copyright`). I'm afraid of figuring some of attributes required, when these assemblies will be used in UWP or cross-platform solutions. Generally, I'd like to go on with `project.json` only. — brutallord, Aug 26 '16 at 10:29

score 30 · Accepted Answer · edited Nov 17 '20 at 00:38

project.json has replaced the AssemblyInfo.

AssemblyVersionAttribute is replaced by version property

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

AssemblyNameAttribute is now the name property

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.

and so on

Update: With the announcement of .NET Core Tools MSBuild, the .csproj has replaced the project.json. The AssemblyInfo.cs file is back, but most of the settings have been moved directly to .csproj. See related SO question for more details: 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>

score 12 · Answer 2 · answered Aug 26 '16 at 12:26

The project.json is not a direct replacement for the AssemblyInfo.cs, so there is still the need if you want to define some values you cannot provide in the project.json.

From the Issue https://github.com/aspnet/dnx/issues/2715 you can see, that in the beginning some parameters, like title, description, copyright, etc. where taken to fill the fields for the generated nuget packages. With the issue 2715 the idea was born, that these values can "flow into the Assembly". So that you have not to configure these fields in two different places. So if you do not want to configure more than these paramters, the the AssemblyInfo.cs is not needed.

There are other fields like [InternalsVisibleTo] that can not be configured in project.json. So there are cases where there is still the need to define one.

Do I need AssemblyInfo while working with .NET Core?

2 Answers2

Linked