Octopuspack change 'Microsoft.NETCore.App', version '5.0.0'

[sn]

Hi Octopus

We are having a problem with OctopusPack in our Azure Devops build pipeline.

When running our normal pipeline today, we get the following error from OctopusPack:
The framework ‘Microsoft.NETCore.App’, version ‘5.0.0’ was not found

This did not occur in our previous pipeline runs for the same tag.

I have attached 2 pipeline raw log files, one where it works and one with the error.

We use .Net Core 3.1.1 in our pipeline, but we also have older pipelines with .Net Core 2.2, which also does not work.

Good build.txt (5.8 KB) Bad build.txt (6.5 KB)

Please advise how to solve this.
Upgrading our code to .Net 5.0 is not possible, since we are in process of migrating accepted codebranches to production.

Best Regard
Søren

[paul.calvert]

Hi @sn,

Thanks for getting in touch!

The latest version of the CLI does require .NET 5 to be available on the build agent; however, you can still use other .NET versions to build your code.

If installing .NET 5 isn’t an option, you can add the Octopus CLI Installer step to your pipeline (ordered before the other Octopus steps) and specify the older CLI version (7.4.3429), which does not require .NET 5.

Regards,
Paul

[sn]

Hi Paul

Thanks for the quick reply.

Any chance you have a link to an example on how to do that.

Our pipeline job looks like this:
…

• job: Migrations
  dependsOn: Test
  condition: succeeded()
  pool:
  vmImage: $(vmImage)
  steps:

  • task: UseDotNet@2
    displayName: ‘Use .NET Core sdk’
    inputs:
    packageType: sdk
    version: 3.1.101
    installationPath: $(Agent.ToolsDirectory)/dotnet

  • task: DotNetCoreCLI@2
    displayName: ‘dotnet restore’
    inputs:
    command: restore
    projects: $(csproj_migrations)
    feedsToUse: config
    nugetConfigPath: NuGet.Config

  • task: DotNetCoreCLI@2
    displayName: ‘dotnet build’
    inputs:
    projects: $(csproj_migrations)

  • task: DotNetCoreCLI@2
    inputs:
    command: ‘publish’
    publishWebProjects: false
    projects: ‘$(csproj_migrations)’
    arguments: ‘–configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)’
    zipAfterPublish: false

  • task: OctopusPack@4
    inputs:
    PackageId: ‘$(nugetName_migrations)’
    PackageFormat: ‘NuPkg’
    PackageVersion: $(Build.BuildNumber)
    SourcePath: ‘$(Build.ArtifactStagingDirectory)’
    OutputPath: ‘$(Build.ArtifactStagingDirectory)/packages’

  • task: DotNetCoreCLI@2
    displayName: ‘dotnet push’
    inputs:
    command: ‘push’
    packagesToPush: ‘$(Build.ArtifactStagingDirectory)/packages/*.nupkg’
    nuGetFeedType: ‘internal’
    publishVstsFeed: ‘XXXXXXXXX’

Best regards
Søren

[paul.calvert]

Sure, adding this before the OctopusPack step should work.

- task: OctoInstaller@4
  inputs:
    version: '7.4.3429'

[sn]

Hi Paul

Thank you, works like a charm

Have a good day

Søren

[andrstor87]

Hi,

Ref: this issue

How can this be a good solution?

Am I forced to use use an old version of the cli untill I have upgraded (all) my applications to 5.0?
And do I have to make our teams edit 50+ pipelines for this to start working again?

How can you silently break my build pipelines with an minor version update? Shouldn’t this be a breaking change, forcing us to update our task / step versions if we want to upgrade?

A workaround could be to manually install the 5.0 runtime on our hosted build-servers, but it does not seem like the octopus-tasks scans other places than the /_tool/ -folder other versjons?

Atleast we should be given a warning so that we can prepare for this breaking change?

Andreas

[paul.calvert]

I completely agree, I believe this is an unintentional change.
We are currently trying to see if we can temporarily hide this version to prevent it being seen as latest and downloaded.
And our engineers will be looking into this as a priority as soon as they are online.

[dougbloch]

Paul is there an update on this breaking change?

[paul.calvert]

Hi @dougbloch,

The version of the CLI that required .NET 5 has been removed from our download site and our engineers performed a full post-mortem to ensure it doesn’t happen again.

If we do reach a point where the .NET requirement of the CLI is going to be raised the plan would be to add a warning that would appear within the build logs to give advanced notice of this.

Regards,
Paul