GitVersion: [Bug] Azure DevOps UseGitVersion@5 task and GitVersion 5.2.4 produces an error "AssemblyInfoFilename file not found at null" when `UpdateAssemblyInfo: true` is set

Describe the bug I have recently been updating pipelines to use the UseGitVersion@5 task, replacing the obsolete GitVersion@5 task. For the most part, this has been easy, and I did not encounter any problems until I switched out the task on a pipeline which use GitVersion to update the AssemblyInfo.cs files for a .Net Framework solution. When run, the build fails on the UseGitVersion@5 task, with the error message:

##[error]Error: AssemblyInfoFilename file not found at null

The task is defined in my pipeline as per the example in the GitVersion docs:

- task: UseGitVersion@5
  inputs:
    versionSpec: '5.x'
    updateAssemblyInfo: true

Expected Behavior

The UseGitVersion@5 task should update all AssemblyInfo.cs files under the repository

Actual Behavior

Task execution fails with the error AssemblyInfoFilename file not found at null.

Possible Fix

Unfortunately, I have nothing concrete to offer beyond wild speculation.

Steps to Reproduce

This may be reproduced using the simple pipeline below, in a repo containing a .Net Framework solution with projects that include AssemblyInfo.cs files. Gitversion.yml file also attached.

See the attached log from pipeline task execution UserGitVersionPipelineTaskLog.log with debugging enabled

Context

No longer able to automate the versioning of assemblies with UseGitVersion@5 as ws possible with GitVersion@5 task.

Your Environment

Azure DevOps Pipelines running on MS hosted Windows Agent

Version Used:

windows-latest MS hosted agent
UseGitVersion@5 - v5.1.2
GitVersion 5.2.4

Sample Pipeline

pool:
  vmImage: 'windows-latest'

steps:
- task: UseGitVersion@5
  inputs:
    versionSpec: '5.x'
    updateAssemblyInfo: true

Sample `GitVersion.yml` config used…nothing to see here really

branches: {}
ignore:
  sha: []
merge-message-formats: {}

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 2
Comments: 23 (8 by maintainers)

Commits related to this issue

GH-2225 use FileSystemGlobbing to resolve AsemblyInfo to be updated — committed to arturcic/GitVersion by arturcic 4 years ago
GH-2225 use FileSystemGlobbing to resolve AsemblyInfo to be updated — committed to arturcic/GitVersion by arturcic 4 years ago
GH-2225 use FileSystemGlobbing to resolve AsemblyInfo to be updated — committed to arturcic/GitVersion by arturcic 4 years ago
GH-2225 use FileSystemGlobbing to resolve AsemblyInfo to be updated — committed to arturcic/GitVersion by arturcic 4 years ago
GH-2225 use FileSystemGlobbing to resolve AsemblyInfo to be updated — committed to arturcic/GitVersion by arturcic 4 years ago
GH-2225 use FileSystemGlobbing to resolve AsemblyInfo to be updated — committed to GitTools/GitVersion by arturcic 4 years ago

Most upvoted comments

So, apparently using the full absolute path to the AssemblyInfo.cs file seems to work:

Sadly, I have multiple AssemblyInfo.cs files to update during a build.

But I would expect something like this to work just fine:

- task: UseGitVersion@5
  displayName: gitversion
  inputs: 
    versionSpec: '5.x'
    updateAssemblyInfo: true
    updateAssemblyInfoFilename: '**/AssemblyInfo.cs'

As would I, but it does not. It was also unnecessary to be explicit about AssemblyInfo.cs file paths in the obsolete GitVersion@5 task. The simplicity of configuration/inputs in the original GitVersion@5 task was a big driver behind why we adopted it in our organization. The UseGitVersion@5 is even better with seemingly even less to express to get it to “do the right thiing” - I don’t believe it was the intent that the behavior of simply setting updateAssemblyInfo: true was meant to break or even change in the UseGitVersion@5 task.

While I appreciate the sentiments and suggestions expressed above, an AssemblyInfo.cs shared across projects is unfortunately not a viable workaround in my particular situation (impacts too many projects).

Also, since a file pattern such as updateAssemblyInfoFilename: '$(Build.SourcesDirectory)/**/AssemblyInfo.cs also does not work, then there has clearly been a regression as compared to the, now deprecated, GitVersion@5 task. The UseGitVersion@5 task appears to be completely incapable of updating multiple AssemblyInfo.cs files, which does not align with either the documented behavior or, as already mentioned, implicit behavior in GitVersion@5.

As an aside, I’ve also noticed a comparatively large performance degradation in UseGitVersion@5 vs GitVersion@5. It seems on average UseGitVersion@5 runs roughly 6-7 times slower at around 30-35 seconds, versus GitVersion@5 which runs in roughly 5-6 seconds on the same agent and repository. This is not a deal-breaker by any means, merely an observation for the feedback bucket.

dsbut on Apr 8, 2020

We are currently experiencing the same issue. No solution found yet.

suddenelfilio on Apr 8, 2020

I encountered this bug in Version 5.3.x, should I create a new Issue?

iamNoah1 on Jun 22, 2020

@arturcic Was the File Globbing implemented this version? I just tried the UseGitVersion task with 5.3.2, checking Update AssemblyInfo, and specifying **/AssemblyInfo.cs. I got an error stating that no such file was found.

However If I add /updateassemblyinfo /diag to the command line arguments parameter, it actually works as intended, indicating it updated the files correctly in the diagnostics output.

svengeance on May 6, 2020