Yet the build didn't pass. It failed with a bizarre error. SpecFlow was failing to generate code-behind files.
Some research made it clear that this was really a function of SpecFlow not working very well with .NET 3.1.200. The surprising thing about that was that I didn't remember switching to 3.1.200.
The fault actually was mine. At least, it was in a circuitous way. It was an artifact of a decision I made while defining my pipeline:
- task: UseDotNet@2
displayName: 'Use .NET 3.1'
inputs:
version: 3.1.x
installationPath: '$(Agent.ToolsDirectory)\dotnet\3.1'
I intentionally chose to allow updates automatically with that little ".x" and it burned me.
Sure enough, a tiny change "fixed" my broken pipeline:
- task: UseDotNet@2
displayName: 'Use .NET 3.1'
inputs:
version: 3.1.102
installationPath: '$(Agent.ToolsDirectory)\dotnet\3.1'
I'll definitely leave it that way until I have a reason to change it.
What I don't know, at this time, is if I'll go back to allowing the maintenance version to float, when I finally do make a change.
Is it better to have the stability of a known version or to get the fixes in the latest version without having to do anything?
Right now, my inclination is toward faster updates, still. For an indie game-development shop with a disciplined developer who jumps on problems right away, it's probably better to get the updates in exchange for the occasional quickly-fixed disruption.
That said, if I get burned like this a few more times, I might change my mind.
