Gitversion: [Bug] Updating Assembly info specifying file resulting in duplicate attributes being defined.

[shaneholder]

Updating Assembly info specifying file resulting in duplicate attributes being defined.

The command line being executed is:

F:\agents\agent00_work_tool\GitVersion.Tool\5.3.3\x64\dotnet-gitversion.exe F:/agents/agent00/_work/12/s /output json /output buildserver /updateassemblyinfo F:\agents\agent00_work\12\s/CommonAssemblyInfo.cs

and at the end of the log I see:

INFO [05/17/20 14:26:17:15] Updating assembly info files
INFO [05/17/20 14:26:17:15] Found 51 files
INFO [05/17/20 14:26:18:21] Done writing

and the errors are CS0579: Duplicate AssemblyVersion, AssemblyFileVersion, AssemblyInformationalVersion attribute

Perhaps I'm missing an option in the build?

Your Environment

Azure Devops:
The following two tasks are configured. I have been using the original GitVersion task for a few years now and I'm just now updating to the new gittools tasks.

steps:
- task: gittools.gittools.setup-gitversion-task.gitversion/setup@0
  displayName: gitversion/setup
  inputs:
    versionSpec: 5.x
  enabled: false

steps:
- task: gittools.gittools.execute-gitversion-task.gitversion/execute@0
  displayName: gitversion/execute
  inputs:
    updateAssemblyInfo: true
    updateAssemblyInfoFilename: '$(Build.SourcesDirectory)/CommonAssemblyInfo.cs'
  enabled: false

[Crossbow78]

We have a similar step in our Azure build pipeline, and what I noticed is that GitVersion 5.3.2 no longer honors the updateAssemblyInfoFilename argument, and updates any 'AssemblyInfo.cs' it finds, instead of our specified 'SharedAssemblyInfo.cs'.

Had some hope that this was covered in #2270, but the issue is still present in 5.3.3.

We reverted to GitVersion 5.2.4 which works fine.

[Miles-Davies-HORIBA]

Hi, to add to this we use the /updateassemblyinfofilename argument followed by a relative path to the git root to a single file. This file is shared by all our projects so we have common version information.
Recent builds have either thrown an invalid argument exception or ignored the file path and just written over any file named "AssemblyInfo.cs" in the entire source tree. This is 100s of files in our case and is not what I would expect.
I think if the approach to handling arguments changes from a file path to a glob pattern maybe a new argument should be used to make it explicit? At the very least the help should be updated to reflect this change. Currently -help describes arguments that cannot be used :-(

[pietergheysens]

Same issue using GitVersion.Tool 5.3.5 x64. The UpdateAssemblyInfoFilename is a valid path but it's ignored during the process. It scans for the regular project AssemblyInfo files and updates these individually. Build fails with the "Duplicate" version attribute errors.

[mcnallys]

Experiencing the same issue on 5.3.7.