I’m using the DevOps pipeline to push my dotnet build to an Octopus cloud instance.
It worked fine until I added the dotnet SDK 3 installer to the devops pipeline
- task: UseDotNet#2
displayName: 'Install .net core 3.0.100'
inputs:
packageType: sdk
version: '3.0.100'
installationPath: $(Agent.ToolsDirectory)/dotnet
The octopus part of my azure-pipelines.yml looks like this:
- task: OctoInstaller#4
inputs:
version: 'latest'
- task: OctopusPush#4
inputs:
OctoConnectedServiceName: 'XXX.octopus.app'
Space: 'Spaces-1'
Package: '$(Build.ArtifactStagingDirectory)/$(Build.DefinitionName).$(Build.BuildNumber).zip'
Replace: 'false'
I have tried every combination of OctoInstaller that I can think of including embedded and explicit version numbers. I keep getting this error message with #4.
Failed to push package. The Octo command line tool is too old to run this task. Please use version 6.10.0 or newer, or downgrade the task to version 3.*.
With OctoInstall#3 I get another error:
Failed to push package. The process '/opt/hostedtoolcache/dotnet/dotnet' failed with exit code 150
Has anyone been able to use dotnet 3 with Octopus deploy? One option
might be to install the octo extension for dotnet but I’m not sure how
you would do that from the azure pipeline. Or to use a Windows build
instead of Ubuntu.
I also noticed an error in the build step.
The specified framework 'Microsoft.NETCore.App', version '2.0.0' was not found.
- The following frameworks were found:
3.0.0 at [/opt/hostedtoolcache/dotnet/shared/Microsoft.NETCore.App]
This means that octopus must be trying to use the dotnet 2 framework.
After looking carefully at the logs, I discovered that OctopusPush was failing because it depends on dotnet 2.0.0. I added in a yml task to install that framework and now it pushes to octopus.
It might be neater to use the dotnet octo tool, as described by TrevorBrooks however I don't know how to install dotnet extensions in the DevOps Pipeline.
Use dotnet octo https://octopus.com/blog/octopus-and-netcore
The blog article explains in detail how to make this work.
For Azure Pipelines follow this article: https://octopus.com/docs/packaging-applications/build-servers/tfs-azure-devops/using-octopus-extension
Keep in mind
The Azure DevOps extension tasks require Octo to be available on the
path when executing on a build agent and must have the .net core 2.0.0
runtime or newer installed. This may not always be possible such as
with the Azure DevOps hosted agents. In order to make this work, all
Octopus tasks will automatically attempt to download and use the
latest version of Octo tools unless they're available on the build
agent as specified above. If you would like to avoid any additional
downloads or to use a specific Octo version then you can by adding the
Octo Installer task to the start of your build definition. No attempt
will be made to download Octo if the capability is detected on your
build agent.
Related
When we run dotnet build on a .net 4.8 app, we get an error message. I attempted to install the developer pack for 4.8. However, that fails and I think the reason it fails is that .NET 4.8 is already installed on the system. What's the right way to resolve this issue?
##[error]C:\Program Files\dotnet\sdk\6.0.300\Microsoft.Common.CurrentVersion.targets(1221,5): Error MSB3644: The reference assemblies for .NETFramework,Version=v4.0 were not found. To resolve this, install the Developer Pack (SDK/Targeting Pack) for this framework version or retarget your application. You can download .NET Framework Developer Packs at https://aka.ms/msbuild/developerpacks
Is it that we cannot use dotnet build for 4.8 apps? Do we need to use MSBuild instead?
It requires the build agent be windows based, e.g. vmImage: 'windows-2022'.
- task: VSBuild#1
displayName: 'Dotnet build'
inputs:
solution: '*.sln'
msbuildArgs: '/t:build /p:DeployOnBuild=true /p:OutputPath="$(Build.ArtifactStagingDirectory)"'
restoreNugetPackages: true
configuration: '$(buildConfiguration)'
The above assumes the solution file is located in the root of the source repository.
While restoreNugetPackages is optional I received package not found errors until enabling it.
We have Xamarin.Forms solution with iOS and UWP projects. We use Azure pipelines to build the iOS project. Until yesterday everything was working fine.
Now the build fails at the NuGet Restore step with the error:
##[error]The nuget command failed with exit code(1) and error(/Users/runner/work/1/s/"MyProjectName.UWP".csproj : error MSB4057: The target "_IsProjectRestoreSupported" does not exist in the project.
We can see that the problem occurs when trying to restore NuGet packages for the UWP project on the Mac OS build host.
Image: macOS-11
Workaround will be to exclude it from the solution, but we are using it for testing purposes and this is not a good option for us.
We had the same problem yesterday for our iOS (macos-11) and Android (macos-10.15) Pipelines.
The issue 21180 for mono seems to be the root cause, which is also referenced in a pull request to update the mono version for MacOs virtual environments. Regarding to this workflow test we gave msbuild a chance, and it works.
Solution:
Instead of NuGet restore we use directly MSBuild.
- task: MSBuild#1
inputs:
solution: 'App.sln'
configuration: 'Release'
msbuildArguments: /t:restore
Looking at the log file, MSBuild ignores the UWP project. That is the behavior that NuGet had with the older mono version 6.12.0.125. Ignoring the UWP-Project is no problem, because it can only be build on windows environments.
Project "/Users/runner/work/1/s/App.sln" on node 1 (Restore target(s)).
ValidateSolutionConfiguration:
Building solution configuration "Release|Any CPU".
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/NuGet.targets(315,5): warning : Skipping restore for project '/Users/runner/work/1/s/App/App.UWP/App.UWP.csproj'. The project file may be invalid or missing targets required for restore. [/Users/runner/work/1/s/App.sln]
Some additional information:
The NuGet restore task uses msbuild to find all referenced packages. If that fails, it will use the packages.config file as fallback, the pipeline step will not fail.
Instead we got an error in the build steps for Android & iOS:
error NETSDK1004: Assets file
'/Users/runner/work/1/s/../obj/project.assets.json' not found. Run a
NuGet package restore to generate this file.
Updated Answer
This can be resolved using MSBuild task instead, as the collogues mentioned below.
However, in my case this still lead to the same error. After investigating the pipeline. The root cause has been identified:
Both in MSBuild#1 and XamariniOS#2 tasks
you should target the specific iOS Project and not the solution file, like so:
"
- task: MSBuild#1
inputs:
solution: 'PathToIosProject/myproject.iOS.csproj'
configuration: '$(BuildConfiguration)'
msbuildArguments: /t:restore
" - task: XamariniOS#2
inputs:
solutionFile: PathToIosProject/myproject.iOS.csproj'
configuration: '$(BuildConfiguration)'
packageApp: true
signingIdentity: $(APPLE_CERTIFICATE_SIGNING_IDENTITY)
Old Answer
We have managed to resolve the issue. The root cause of it seems to be an update to the mono framework in the MacOS pipeline build agent.
In order to fix it, we need a script for downloading and installing an older version of the mono framework as a first step of the build pipeline like so:
link to the pipeline tasks photo
This is the code of the bash scrip used in the task:
#!/bin/bash
set -ex
MONO_MACOS_PKG_DOWNLOAD_URL='https://download.mono-project.com/archive/6.12.0/macos-10-universal/MonoFramework-MDK-6.12.0.100.macos10.xamarin.universal.pkg'
mkdir -p /tmp/mono-install
cd /tmp/mono-install
mono --version
wget -q -O ./mono-installer.pkg "$MONO_MACOS_PKG_DOWNLOAD_URL"
sudo installer -pkg ./mono-installer.pkg -target /
mono --version
ls -alh /Library/Frameworks/Mono.framework/Versions/Current
In our pipeline for the past 3 weeks, the dotnet test task has not been terminating at all, and we are forced to cancel the pipeline.
We have observed this log, which we had not seen prior to 3 weeks: (No changes have been made in these 3 weeks at all, either to our code or to Windows on our on premise agent, SQL Server or any other service in the agent).
The STDIO streams did not close within 10 seconds of the exit event from process 'C:\AzAgent_work_tool\dotnet\dotnet.exe'. This may indicate a child process inherited the STDIO streams and has not yet exited.
##[error]Error: The process 'C:\AzAgent_work_tool\dotnet\dotnet.exe' failed with exit code 1
All the tests in the task pass though.
Publishing test results to test run '1033120'.
TestResults To Publish 233, Test run id:1033120
Test results publishing 233, remaining: 0. Test run id: 1033120
Published Test Run :
The test results are published.
We have observed this in the logs:
*##[warning].NET 5 has some compatibility issues with older Nuget versions(<=5.7), so if you are using an older Nuget version(and not dotnet cli) to restore, then the dotnet cli commands (e.g. dotnet build) which rely on such restored packages might fail. To mitigate such error, you can either: (1) - Use dotnet cli to restore, (2) - Use Nuget version 5.8 to restore, (3) - Use global.json using an older sdk version(<=3) to build
Info: Azure Pipelines hosted agents have been updated and now contain .Net 5.x SDK/Runtime along with the older .Net Core version which are currently lts. Unless you have locked down a SDK version for your project(s), 5.x SDK might be picked up which might have breaking behavior as compared to previous versions. You can learn more about the breaking changes here: https://learn.microsoft.com/en-us/dotnet/core/tools/ and https://learn.microsoft.com/en-us/dotnet/core/compatibility/ . To learn about more such changes and troubleshoot, refer here: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#troubleshooting*
Hence we added this in our yaml before the test task, as our app is built with .NET Core 3.1:
- task: UseDotNet#2
inputs:
packageType: sdk
version: 3.x
installationPath: $(Agent.ToolsDirectory)/dotnet
displayName: 'Installing .net core sdk 3.x'
condition: succeeded()
I did a little investigation and found this link on the MS github page: https://github.com/microsoft/azure-pipelines-tasks/issues/13033
We have set these variables: TASKLIB_TEST_TOOLRUNNER_EXITDELAY 60000
name: 'NUGET_PLUGIN_REQUEST_TIMEOUT_IN_SECONDS'
value: 30
name: 'NUGET_PLUGIN_HANDSHAKE_TIMEOUT_IN_SECONDS'
value: 30
No effect yet. How can we solve this issue? It is not affecting our release but we would like to have a green pipeline? Tips on this would be greatly helpful
Thanks for Ashwin's answer.
There was an issue with chromedriver exe which used was not updated for chrome 89. Hence one of the tests was hanging. So then after changing the chromedriver and removing the filter, the tests ran fine and the stage terminated. So no changes to pipeline yaml were required.
Posting here so others who have the same issue can find this answer quickly.
I'm trying to build a Release pipeline that is triggered by a new version of a published dotnet core tool. The trigger works fine, but I'm unable to install and run the tool in my Tasks.
CURRENTLY:
Running a Command Line Task results in a 401:
dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp
C:\Program Files\dotnet\sdk\3.0.100\NuGet.targets(123,5): error : Unable to load the service index for source https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json. [C:\Users\VssAdministrator\AppData\Local\Temp\h0g1c35v.eny\restore.csproj]
C:\Program Files\dotnet\sdk\3.0.100\NuGet.targets(123,5): error : Response status code does not indicate success: 401 (Unauthorized). [C:\Users\VssAdministrator\AppData\Local\Temp\h0g1c35v.eny\restore.csproj]
The tool package could not be restored.
Tool 'myapp' failed to install. This failure may have been caused by:
* You are attempting to install a preview release and did not use the --version option to specify the version.
* A package by this name was found, but it was not a .NET Core tool.
* The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem.
* You mistyped the name of the tool.
For more reasons, including package naming enforcement, visit https://aka.ms/failure-installing-tool
This leads me to believe that I'm missing something here, making it more complicated than it needs to be, or thinking about this the wrong way. The tools in the feed can be installed locally, so I believe it's my release approach.
I'm currently looking into Personal Access Tokens (PAT)
PREVIOUSLY:
If I use the .Net Core task and the custom option:
The logs show a malformed command passed to dotnet.exe:
[command]"C:\Program Files\dotnet\dotnet.exe" "dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp"
or
[command]"C:\Program Files\dotnet\dotnet.exe" "tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp"
I've tried varying arguments and I tend to always see the same error message:
Could not execute because the specified command or file was not found.
Possible reasons for this include:
* You misspelled a built-in dotnet command.
* You intended to execute a .NET Core program, but dotnet-dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp does not exist.
* You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.
Your custom dotnet command is quoted and dotnet is repeated : dotnet.exe" "dotnet tool install ..." so the command is misinterpreted.
You can use the Command Line task and set the dotnet command directly :
dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp
Using the .Net Core task works perfect for us.
Since the dotnet command is quoted, you need to set tool as the command and update into arguments. NuGet credentials can be provided with NuGet Auth task if needed.
Here is my walkaround:
I firstly published my private dotnet tool nupkg file also as an universal package to the same Azure Artifacts feed.
I was able to then use Universal Package task to download the .nupkg file into $(System.DefaultWorkingDirectory)/nupkgs/. This task will handle the authorization to Azure Artifacts feeds.
steps:
- task: UniversalPackages#0
displayName: 'Download mytool.cli.universal'
inputs:
downloadDirectory: '$(System.DefaultWorkingDirectory)/nupkgs/'
vstsFeed: '63d4aa2f-3ae7-4c27-8c18-aa8e3a9ff353'
vstsFeedPackage: '916d9a27-2c07-4071-8631-377f2ac08ed7'
vstsPackageVersion: 0.2.0
I then had the DotNetCoreCLI task to install my nupkg locally in agents.
steps:
- task: DotNetCoreCLI#2
displayName: 'Install mytool as a dotnet tool'
inputs:
command: custom
custom: tool
arguments: 'install --global mytool.CLI --add-source ./nupkgs --version 0.2.0'
You need to add the nuget authenticate task before you try to access the nuget feed
I am using a DotNetCoreCLI task to build a project. But I would like to build it with MSBuild 16.0 what seems to be not possible so far. Here are the facts (snippet from Azure Pipelines Yaml):
pool:
vmImage: 'windows-2019'
steps:
- task: DotNetCoreCLI#2
displayName: 'dotnet build'
inputs:
projects: '$(BuildProjectFilter)'
arguments: '--configuration $(BuildConfiguration) -:Platform=$(BuildPlatform) -p:VisualStudioVersion=16.0 -p:tv=16.0'
No matter what I try the dotnet build command always uses ToolsVersion 15.0:
==============================================================================
Task : .NET Core
Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command
Version : 2.156.1
Author : Microsoft Corporation
Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
==============================================================================
[command]C:\windows\system32\chcp.com 65001
Active code page: 65001
[command]"C:\Program Files\dotnet\dotnet.exe" build d:\a\1\s\src\xxx.csproj --configuration release -p:Platform=x64 -p:VisualStudioVersion=16.0 -p:tv=16.0
Microsoft (R) Build Engine version 15.9.20+g88f5fadfbe for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
If I only supply the -tv:16.0 switch MSBuild complains:
MSBUILD : error MSB1040: ToolsVersion is not valid. The tools version "16.0" is unrecognized. Available tools versions are "15.0".
If I supply -p:VisualStudioVersion=16.0 -p:tv=16.0 in combination the Error is recognized later by Fody telling me
Fody is only supported on MSBuild 16 and above. Current version: 15.
Of course, downgrading Fody might be a solution. But I would prefer to use MSBuild 16 as it should be available in this vm image. Is there a way to achieve that?
I think you'd better specified the higher version of .NET core SDk 2.2.401 in your task.
If I use SDK 2.2.101 to build project, I will receive the same error message with you:
To explain this, you can see the below content which mentioned in the doc:
If the .Net Core SDK version you used is lower than 2.2.401, since these lower version SDK could not be compatible with VS2019. At this time, even you specified VS 2019, it will still use the build engine which belong to VS2017. That's why in your first error log, the build engine this pipeline used is 15.9.20+g88f5fadfbe
Microsoft (R) Build Engine version 15.9.20+g88f5fadfbe for .NET Core
As test, after I build project with the .Net Core SDK which version is 2.2.401, as the below pic you see:
The MSbuild version it took is 16. So, it satisfied the definition of the underlying fody file:
This is part of the underlying fody file. You can see, it is defined as only your MSbuild version is 16, or it will throw the error message like you received.
So, to solve your issue, I recommend you try with specifying the .Net Core SDK as 2.2.401 or above version in the task.