5

I have migrated project of WPF in Asp.Net framework into Asp.Net core. Existing .net projects have AssemblyInfo.cs inside properties folder.when creating new WPF project using "dotnet new wpf". AssemblyInfo.cs file gets added.

AssemblyInfo.cs in .Net framework have all information but the one in dot net core doesn't have any information

Planning to delete new one created for core since getting build issue as "duplicate ThemeInfo attribute" and disable old one which got migrated from .Net framework using add below properties in the csproj

<ItemGroup>   
   <Compile Remove="Properties\AssemblyInfo.cs" />   
</ItemGroup>   
<ItemGroup>   
  <None Include="Properties\AssemblyInfo.cs" />   
</ItemGroup> 

Need to know if is this needed for Net core project.

Karthic G
  • 1,162
  • 1
  • 14
  • 31

2 Answers2

11

AssemblyInfo.cs is useful, but it's not necessary.

In .NetCore you can manage AssemblyInfo from the .csproj file instead of AssemblyInfo.cs file. The AssemblyInfo.cs file will be autogenerated in obj folder for you. All you need to do is to set its properties in the csproj file:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <AssemblyName>myAppName</AssemblyName>
  </PropertyGroup>
</Project>

The compiler will complain about duplicate properties if there is an AssemblyInfo.cs file present in your project with any properties set. In this case you should set GenerateAssemblyInfo to false (so that it doesn't auto-generate an x.AssemblyInfo.cs into obj folder):

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
    <AssemblyName>myAppName</AssemblyName>
  </PropertyGroup>
</Project>

You can choose to handle the assembly information manually (through AssemblyInfo.cs files instead of through .csproj file) just by setting auto-generate attributes to false. For example you may set GenerateAssemblyInfo to false to prevent auto-generation of the AssemblyInfo.cs or you may set GenerateAssemblyTitleAttribute to false to prevent auto-generation of Title attribute inside AssemblyInfo.cs. This means you can set the assembly information in both AssemblyInfo and csproj. This comes in handy when you want to share a common set of information between different projects, while being able to change some info in each of them. (You can't set a property twice though, but still this is a useful feature)


Just a side note: Since you've migrated to .NetCore you might as well want to migrate your csproj into Project SDK format, if you haven't already done it. Then you will notice a lot of clutter disappearing from csproj making it more readable and easier to maintain, putting more focus on those mentioned properties.

There is a way to do the same thing in Classic .Net Applications: https://github.com/dasMulli/AssemblyInfoGenerationSdk

Bizhan
  • 16,157
  • 9
  • 63
  • 101
0

Properties/AssemblyInfo.cs should be removed when you upgrade your project from .NET Framework to .NET Core or .NET 5 or .NET 6. As you saw, you will get build errors otherwise. Instead, the info that was in there now should be stored directly in the .csproj file.

Justin
  • 17,670
  • 38
  • 132
  • 201
  • I haven't seen in any docs mentioning this. AFAIK AssemblyInfo remains as a valid option, as the auto-generated assembly info is also the default option. – Bizhan Apr 16 '21 at 13:51
  • It doesn't seem that way to me, everything I read when I was performing the conversion myself spelled out that you should delete AssemblyInfo and instead store these values in the csproj file. If you want to share common values between different csproj files, then having Directory.Build.props file is the way to go IMO. – Justin Apr 17 '21 at 12:28
  • I think you're mistaken @Justin. It's a choice. You can either auto generate assemblyinfo from csproj OR choose to keep assemblyinfo and not auto generate it. – Andy Apr 17 '21 at 17:04
  • 1
    @Justin yes Directory.Build.props is a clean way of doing it. But it's important to know that AssemblyInfo is how .net sets those information in assemblies. it hasn't been changed since .NetFx. The only thing that has changed is it's now being auto-generated by-default (which you can set not to). – Bizhan Apr 17 '21 at 23:52