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
The UseGitVersion@5 task should update all AssemblyInfo.cs files under the repository
Task execution fails with the error AssemblyInfoFilename file not found at null.
Unfortunately, I have nothing concrete to offer beyond wild speculation.
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
No longer able to automate the versioning of assemblies with UseGitVersion@5 as ws possible with GitVersion@5 task.
Azure DevOps Pipelines running on MS hosted Windows Agent
windows-latest MS hosted agentUseGitVersion@5 - v5.1.2pool:
vmImage: 'windows-latest'
steps:
- task: UseGitVersion@5
inputs:
versionSpec: '5.x'
updateAssemblyInfo: true
GitVersion.yml config used...nothing to see here reallybranches: {}
ignore:
sha: []
merge-message-formats: {}
We are currently experiencing the same issue. No solution found yet.
We have encountered the same issue today.
trigger:
- master
- feature/*
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
GitVersion.SemVer: ''
DOTNET_SKIP_FIRST_TIME_EXPERIENCE: true
DOTNET_CLI_TELEMETRY_OPTOUT: true
steps:
- task: NuGetToolInstaller@1
- task: NuGetCommand@2
inputs:
restoreSolution: '$(solution)'
- task: UseGitVersion@5
displayName: gitversion
inputs:
versionSpec: '5.x'
updateAssemblyInfo: true
mode: ContinuousDeployment
next-version: 1.0
assembly-versioning-scheme: MajorMinorPatch
assembly-file-versioning-scheme: MajorMinorPatchTag
assembly-informational-format: '{InformationalVersion}'
increment: Inherit
continuous-delivery-fallback-tag: ci
tag-prefix: '[vV]'
major-version-bump-message: '\+semver:\s?(breaking|major)'
minor-version-bump-message: '\+semver:\s?(feature|minor)'
patch-version-bump-message: '\+semver:\s?(fix|patch)'
no-bump-message: '\+semver:\s?(none|skip)'
legacy-semver-padding: 4
build-metadata-padding: 4
commits-since-version-source-padding: 4
commit-message-incrementing: Enabled
commit-date-format: 'yyyy-MM-dd'
merge-message-formats: {}
If I specify the full path to the assembly info file
- task: UseGitVersion@5
displayName: gitversion
inputs:
versionSpec: '5.x'
updateAssemblyInfo: true
updateAssemblyInfoFilename: 'src/Project/Properties/AssemblyInfo.cs'
We get a slightly different error:
##[error]Error: AssemblyInfoFilename file not found at src/Project/Properties/AssemblyInfo.cs
The path to the assembly file is correct so that is not the issue.
So, apparently using the full absolute path to the AssemblyInfo.cs file seems to work:
- task: UseGitVersion@5
displayName: gitversion
inputs:
versionSpec: '5.x'
updateAssemblyInfo: true
updateAssemblyInfoFilename: '$(Build.SourcesDirectory)/src/Project/Properties/AssemblyInfo.cs'
Using a shared GlobalAssemblyInfo.cs file combined with this configuration might be a suitable workaround. 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'
And perhaps this could even be the default convention?
The only remaining issue at this point is that we now get this warning:
Warning : File contains assembly version attributes which conflict with the attributes generated by GitVersion Properties\AssemblyInfo.cs
Which seems weird, because we don't have any version-related properties in the assembly info file:
using System.Reflection;
using System.Runtime.InteropServices;
// General Information about an assembly is controlled through the following
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
[assembly: AssemblyTitle("Project")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("Company NV")]
[assembly: AssemblyProduct("Product")]
[assembly: AssemblyCopyright("Copyright 漏 2020")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]
// Setting ComVisible to false makes the types in this assembly not visible
// to COM components. If you need to access a type in this assembly from
// COM, set the ComVisible attribute to true on that type.
[assembly: ComVisible(false)]
// The following GUID is for the ID of the typelib if this project is exposed to COM
[assembly: Guid("10aa69b4-2816-44a2-8097-1385fcb369c7")]
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.
Hi @arturcic
Now that this issue is closed, do we simply need to wait for the 5.3.0 release of GitVersion in order for the UseGitVersion@5 task to work when defined as below? Or, is there more to it than that?
- task: UseGitVersion@5
inputs:
versionSpec: '5.x'
updateAssemblyInfo: true
Kind of yes, but I test with the GitTools extension not UseGitversion. As we're moving to the GitTools extension, the UseGitversion will be obsolete
:tada: This issue has been resolved in version 5.3.0 :tada:
The release is available on:
Your GitReleaseManager bot :package::rocket:
@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.
I can't seem to get it to work
Use GitTools instead of UseGitversion
With GitTools I get
Starting: gitversionexecute
Task : Execute GitVersion Task
Description : Easy Semantic Versioning (http://semver.org) for projects using Git
Version : 0.9.3
Author : GitTools Contributors
Help : See the documentation for help
Finishing: gitversionexecute
That is weird, do you have any assembly info?
Looks like it cannot find one
Yes its in the Properties folder of the project
Is it public project?
Its a private project .. I can share it using email?
Works for me
I'm also having the same issue with GitTools on Azure DevOps.
Starting: gitversionexecute
==============================================================================
Task : Execute GitVersion Task
Description : Easy Semantic Versioning (http://semver.org) for projects using Git
Version : 0.9.3
Author : GitTools Contributors
Help : See the [documentation](https://gitversion.net/docs/) for help
==============================================================================
##[error]Error: AssemblyInfoFilename file not found at **/AssemblyInfo.cs
Finishing: gitversionexecute
Extract from the build YAML:
- task: gitversion/execute@0
inputs:
useConfigFile: true
configFilePath: 'GitVersion.yml'
updateAssemblyInfo: true
updateAssemblyInfoFilename: '**/AssemblyInfo.cs'
I've also tried without specifying the AssemblyInfo Filename:
Starting: gitversionexecute
==============================================================================
Task : Execute GitVersion Task
Description : Easy Semantic Versioning (http://semver.org) for projects using Git
Version : 0.9.3
Author : GitTools Contributors
Help : See the [documentation](https://gitversion.net/docs/) for help
==============================================================================
##[error]Error: AssemblyInfoFilename file not found at undefined
Finishing: gitversionexecute
Build task:
- task: gitversion/execute@0
inputs:
useConfigFile: true
configFilePath: 'GitVersion.yml'
updateAssemblyInfo: true
I got a similar issue and opened an issue in the GitVersion Actions repo.
I encountered this bug in Version 5.3.x, should I create a new Issue?
Has this been corrected yet?
Most helpful comment
Sadly, I have multiple
AssemblyInfo.csfiles to update during a build.As would I, but it does not. It was also unnecessary to be explicit about
AssemblyInfo.csfile paths in the obsoleteGitVersion@5task. The simplicity of configuration/inputs in the originalGitVersion@5task was a big driver behind why we adopted it in our organization. TheUseGitVersion@5is 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 settingupdateAssemblyInfo: truewas meant to break or even change in theUseGitVersion@5task.While I appreciate the sentiments and suggestions expressed above, an
AssemblyInfo.csshared 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.csalso does not work, then there has clearly been a regression as compared to the, now deprecated,GitVersion@5task. TheUseGitVersion@5task appears to be completely incapable of updating multipleAssemblyInfo.csfiles, which does not align with either the documented behavior or, as already mentioned, implicit behavior inGitVersion@5.As an aside, I've also noticed a comparatively large performance degradation in
UseGitVersion@5vsGitVersion@5. It seems on averageUseGitVersion@5runs roughly 6-7 times slower at around 30-35 seconds, versusGitVersion@5which 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.