'git checkout slns between old and new csproj formats

We recently ran the csproj migration tool on our solution with 156 projects:

dotnet tool install --global Project2015To2017.Migrate2019.Tool

This worked very well although we had to do a few modifications. However it has caused a problem where switching between branches before and after the change causes problems with the assemblyinfo.

The error is:

Duplicate 'global::System.Runtime.Versioning.TargetFrameworkAttribute' attribute [PROJECTNAME]

I believe this is because the new format is putting an assemblyinfo.cs and the old style csproj is somehow picking this up? You can see this here where it takes issue with a file:

PROJECTNAMEe\obj\x64\Debug\.NETFramework,Version=v4.7.2.AssemblyAttributes.cs

This can be fixed by running:

1.  Close Visual studio/Rider
2.  git clean -xfd
3.  Get-ChildItem . -Include obj, .vs -Recurse -force | Remove-Item -Recurse -Force
4.  Rebuild solution

Now this works but it's irritating that we constantly have to remind ourselves to do this. Is there a way to modify our new csprojs to make it not do this?

c++sharpmsbuildcsproj


Solution 1:[1]

In the new project style, the assembly info related properties are defined in the .csproj project file, whereas the old style has this in the AssemblyInfo.cs file.

At build time, these go into an auto generated .cs file;
here that .NETFramework,Version=v4.7.2.AssemblyAttributes.cs file.

Since that file is outside of the project, it doesn't get cleaned up when switching project styles (via branche switches).

This ends up in these CS0579 errors because of the conflicts with the info in the AssemblyInfo.cs files in your old project styled projects.

You can prevent the new style projects from auto generating such AssemblyAttributes.cs files, by adding the below setting in the .csproj file.

This then does mean that you have to restore these AssemblyInfo.cs files in the already converted projects.

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

If possible, you might run the migration again and apply the keep-assembly-info flag.

keep-assembly-info instructs the migrate logic to keep the assembly info file.

Alternatively (in case these old project style branches are rather temporary and for time being), you might also consider to clone the repository a second time to a separate path when working on these branches. Doing so they don't share the same output folders.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1

Related Questions