Equivalent to AssemblyInfo in dotnet core/csproj

Question

Since dotnet core moved back to the .csproj format, there is a new autogenerated MyProject.AssemblyInfo.cs which contains, among others:

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

Note that this is automatically regenerated every build. Previously, the file was found in the /obj/ directory, now it appears to be only in memory as the file can't be found on disk and clicking the error message does not open any file.

This is the error message:

Since they are defined there, I can't define them myself in the classical AssemblyInfo.cs.

Where/how can I define the Company and Version of a project?

Novara

Note that this is not strictly related to dotnet core. This is rather related to the new .csproj based format. It's perfectly fine to use this new .csproj format with targeting the old .NET Framework, for example net461 – Lands

Answer 1

As you've already noticed, you can control most of these settings in .csproj.

If you'd rather keep these in AssemblyInfo.cs, you can turn off auto-generated assembly attributes.

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

If you want to see what's going on under the hood, checkout Microsoft.NET.GenerateAssemblyInfo.targets inside of Microsoft.NET.Sdk.

Snapdragon

NuGet doesn't read AssemblyInfo.cs. You still have to use MSBuild properties to define the NuGet package version. – Snapdragon

when the file is auto generated, how to set the InternalsVisibleTo attribute in the new csproj format? – Rappee

@Rappee this isn't one of the auto-generated attributes. Create an empty .cs file somewhere in your project and add the InternalsVisibleTo code to it – Snapdragon

We ran into an issue with this, when out .NET Core app was referencing projects that use the <GenerateAssemblyInfo>false</GenerateAssemblyInfo> setting. #48344181 – Linage

If you put a Directory.build.props file at the root of your solution and add the required attributes - there are not many good reasons to cling to using AssemblyInfos for version info etc. Even if you have legacy tooling (as I do). Admittedly, I still use AssemblyInfo for InternalsVisibleTo – Misteach

@Misteach there are many good reasons to "cling to" AssemblyInfos. They're easier to share and edit for a start. If it's a new year and I need to change the date on my Copyright attribute, or if I decide to change the text in the Company attribute, etc., I do NOT want to have to open hundreds of projects or dozens of solutions individually to do it, and I don't want to have to hand-edit .csproj files either. With AssemblyInfo it was easy - Shared.AssemblyInfo.cs, added as a link in the IDE UI. Every hack to workaround the new way of doing things is harder than that and is a waste of dev time. – Sextuplicate

InternalsVisibleTo can also be put into the "csproj" file, see here: #42811205. – Secondrate

@Sextuplicate But @Misteach already told you you can use Directory.build.props which has more advantage than your solution because you don't have to modify every project to add this Shared.AssemblyInfo.cs file as link. You don't have to teach developers that they should add it when they create new project and check it on code review. It just works for all current and new projects automatically. How doing nothing is "harder" than having to remember to modify csproj. – Underskirt

@MariuszPawelski Can you point at how to dynamically change copyright year with dotnet core way of doing AssemblyInfo? – Sixty

@OutOfTouch Example: <Copyright>Copyright © 2016-$([System.DateTime]::Now.ToString("yyyy"))</Copyright> – Overdue

How do you manage Directory.build.props to work, it only sets Copyright for me, every other attribute seems to be ignored :/ – Vacuous

Answer 2

Those settings have moved into the .csproj file.

By default, they don't show up but you can discover them from Visual Studio 2017 in the project properties Package tab.

Once saved those values can be found in 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>

In the file explorer properties information tab, FileVersion is shown as "File Version" and Version is shown as "Product version"

Novara

The settings in the project properties seem to be missing if my project type is Class Library (.NET Standard). Do you have any idea why? I'm using Version 15.1, Release 26403.7, Community Edition. – Edrei

I'm using Class Library (.NET Standard) and see it in the Packages tab. Do you see it there? Once you "Save" something other than the defaults, it will show up in the csproj. – Clarisclarisa

How do you use a wildcard like 1.0.*.* when using the packages tab? – Roguery

@Soenhay, wildcarding doesn't make much sense when defining the package version, only when consuming it. – Mathi

@Roguery my understanding is that you can't unless you use similar feature in third party tools. – Novara

To complete the answer, the key to add the "file description", in explorer property window, is <AssemblyTitle>My file description</AssemblyTitle>. – Tachometer

Answer 3

I do the following for my .NET Standard 2.0 projects.

Create a Directory.Build.props file (e.g. in the root of your repo) and move the properties to be shared from the .csproj file to this file.

This also enables central management of these shared properties in a multi project solution, allowing for example to set the copyright and/or version numbers only once for all projects.

MSBuild will pick it up automatically and apply them to the autogenerated AssemblyInfo.cs.

They also get applied to the nuget package when building one with dotnet pack or via the UI in Visual Studio 2017.

See https://learn.microsoft.com/en-us/visualstudio/msbuild/customize-your-build

Example:

<Project>
    <PropertyGroup>
        <Company>Some company</Company>
        <Copyright>Copyright © 2020</Copyright>
        <AssemblyVersion>1.0.0.1</AssemblyVersion>
        <FileVersion>1.0.0.1</FileVersion>
        <Version>1.0.0.1</Version>
        <!-- ... -->
    </PropertyGroup>
</Project>

Dreher

I added Directory.Build.props to the root of my solution, updated it to set my Company, Product, and Copyright, then built the solution. When I open any of the projects, they do not have the correct values for those three fields. What am I missing? – Baerl

@Justin, you won't see them within your project files; they get applied on the resulting built assemblies. – Dreher

What about those of us who do not use msbuild? – Taught

This is nice. But there are other scenarios, when extremely large, multi-solution build, with some projects .Net Standard, others - .Net FW/different versions, etc.? When third party tools do the versioning, and some other, additional and custom properties are set by them. – Disquisition

Perfect solution for my case! Thx :-) – Saire

Worked for me for .Net 6 and VS 2022. – Travail

It also worked when those lines were in the .csproj file, which seems a more elegant solution. – Travail

works with dotnet publish too – Unroll

Answer 4

You can always add your own AssemblyInfo.cs, which comes in handy for InternalsVisibleToAttribute, CLSCompliantAttribute and others that are not automatically generated.

Adding AssemblyInfo.cs to a Project

1. In Solution Explorer, right click on <project name> > Add > New Folder.

2. Name the folder "Properties".

3. Right click on the "Properties" folder, and click Add > New Item....

4. Select "Class" and name it "AssemblyInfo.cs".

Suppressing Auto-Generated Attributes

If you want to move your attributes back to AssemblyInfo.cs instead of having them auto-generated, you can suppress them in MSBuild as natemcmaster pointed out in his answer.

Chelton

I would avoid assuming everyone has Visual Studio these days, there are other editors that could be used making this answer difficult to follow for some (eg I'm doing this on a Mac/Mono using Jetbrains Rider) – Misteach

Sometimes, new Microsoft leads should consider keeping what works well with AssemblyInfo.cs so automated builds can still work to modify the build numbers. – Bust

And if you're like me looking to avoid creating your own AssemblyInfo.cs just for InternalsVisibleToAttribute there is a way as @meziantou wrote in his blog post meziantou.net/declaring-internalsvisibleto-in-the-csproj.htm – Titmouse

@Titmouse - Thanks. Actually, we do use that approach, except for we have further improved it by having it auto-generate the PublicKey for strongly named assemblies if the option is enabled: github.com/apache/lucenenet/blob/…. It wasn't working for CLSCompliant, though, because it quoted the value automatically. See: github.com/dotnet/msbuild/issues/2281. Looks like that may have been fixed now, also. – Chelton

Answer 5

Adding to NightOwl888's answer, you can go one step further and add an AssemblyInfo class rather than just a plain class:

Quilt

There is no "Assembly Information File" when I am open this dialog in VS2019 for a netstandard 1.1 Project. – Wartow

Thanks for posting this! I am using .NET Core 3.1 and it was right there! It adds all the key default parts. – Bust

Answer 6

I want to extend this topic/answers with the following. As someone mentioned, this auto-generated AssemblyInfo can be an obstacle for the external tools. In my case, using FinalBuilder, I had an issue that AssemblyInfo wasn't getting updated by build action. Apparently, FinalBuilder relies on ~proj file to find location of the AssemblyInfo. I thought, it was looking anywhere under project folder. No. So, changing this

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

did only half the job, it allowed custom assembly info if built by VS IDE/MS Build. But I needed FinalBuilder do it too without manual manipulations to assembly info file. I needed to satisfy all programs, MSBuild/VS and FinalBuilder.

I solved this by adding an entry to the existing ItemGroup

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

Now, having this item, FinalBuilder finds location of AssemblyInfo and modifies the file. While action None allows MSBuild/DevEnv ignore this entry and no longer report an error based on Compile action that usually comes with Assembly Info entry in proj files.

C:\Program Files\dotnet\sdk\2.0.2\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.DefaultItems.targets(263,5): error : Duplicate 'Compile' items were included. The .NET SDK includes 'Compile' items from your project directory by default. You can either remove these items from your project file, or set the 'EnableDefaultCompileItems' property to 'false' if you want to explicitly include them in your project file. For more information, see https://aka.ms/sdkimplicititems. The duplicate items were: 'AssemblyInfo.cs'

Disquisition

Answer 7

Thanks, this helped me a lot.

In my case, building the project Blazor Server Side Website was successful both on Release and Debug, but publishing the website still failed with the Duplicate Attribute error, which confused me a bit.

The solution was to add <GenerateAssemblyInfo>false</GenerateAssemblyInfo> both to the .csproj and .pubxml file:

Path: <Project>/Properties/PublishProfiles/<ProfileName>.pubxml:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0"
    xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        ...
        <!-- Add the line below -->
        <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
    </PropertyGroup>
</Project>

Karbala

Answer 8

With .NET 5+, you can use AssemblyMetadata:

<AssemblyMetadata Include="Bar" Value="Baz" />

Adopt

The answer doesn't explain how it addresses the questions. – Novara

Any msdn / doc / other resources about this? – Bainmarie

The answer also doesn't explain where this pice of code goes? Does it go to csproj file? – Vacuous