I'm begginer to devops. And I got a task to create 2 pipelines. One for building project and publishing it to artifact feed. And another pipeline is to run that tool.
First one I have created (created nuget as a tool and placed in my feed).
How can I now create pipeline that will do dotnet run but from my feed?
I just need guidance a big picture.
I'm trying something like this:
pool:
vmImage: windows-latest
jobs:
- job: RunTool
displayName: Run Tool
steps:
- task: DotNetCoreCLI#2
inputs:
command: 'custom'
custom: 'tool'
arguments: 'install -g --add-source=https://pkgs.dev.azure.com/EPMC-STC/ab5c31ad-1d77-4369-80f4-ff2f14a12667/_packaging/MilanDjukicFeed/nuget/v3/index.json MigrationApp --version 8.0.18'
I'm getting:
Installed an ASP.NET Core HTTPS development certificate.
To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only).
Learn about HTTPS: https://aka.ms/dotnet-https
----------------
Write your first app: https://aka.ms/dotnet-hello-world
Find out what's new: https://aka.ms/dotnet-whats-new
Explore documentation: https://aka.ms/dotnet-docs
Report issues and find source on GitHub: https://github.com/dotnet/core
Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli
--------------------------------------------------------------------------------------
C:\Users\VssAdministrator\AppData\Local\Temp\d49e97f8-e901-42d7-8c3e-d1eca71c6055\restore.csproj : error NU1301: Unable to load the service index for source https://pkgs.dev.azure.com/EPMC-STC/ab5c31ad-1d77-4369-80f4-ff2f14a12667/_packaging/MilanDjukicFeed/nuget/v3/index.json.
The tool package could not be restored.
Tool 'migrationapp' 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 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
##[error]Error: The process 'C:\Program Files\dotnet\dotnet.exe' failed with exit code 1
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://docs.microsoft.com/en-us/dotnet/core/tools/ and https://docs.microsoft.com/en-us/dotnet/core/compatibility/ . To learn about more such changes and troubleshoot, refer here: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#troubleshooting
##[error]Dotnet command failed with non-zero exit code on the following projects :
Finishing: DotNetCoreCLI
On Artifacts I have MigrationApp nuget package. I can download it and run it localy.
Since you are creating Nuget as tool and need to use it in pipeline, you can use dotnet tool install command to install the Nuget tool and define the feed source.
For example: Add a command line task/ Bash task/ PowerShell
dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/<projectname>/_packaging/<feedname>/nuget/v3/index.json toolname
Then you can use the nuget tool in next tasks.
On the other hand, if you need to download the Nuget Package, you can use the task: Download package task to download the nuget package from feed and do next actions.
Related
I get an error like this while i run a pipeline in azure-dev-ops.
##[error]C:\Program Files\dotnet\sdk\6.0.203\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(267,5):
Error NETSDK1005: Assets file
'D:\a\1\s\BlazorAppDB\Server\obj\project.assets.json' doesn't have a
target for 'net6.0'. Ensure that restore has run and that you have
included 'net6.0' in the TargetFrameworks for your project.
The project which is a blazor wasm project, perfectly runs and publishes from the Visual studio 2022 - however, when its run from a pipeline from azure-dev-ops I get this error
Can some one point as to where to fix this one. I understand its more of an configuration error than functional error.
Error NETSDK1005: Assets file 'D:\a\1\s\BlazorAppDB\Server\obj\project.assets.json' doesn't have a target for 'net6.0'. Ensure that restore has run and that you have included 'net6.0
The issue can be related to the nuget tool version you used in your pipeline.
When you use a lower version of Nuget tool (e.g. 4.4.1), it will not be compatible with .net6.0.
To solve this issue, you can add NuGet tool installer Task to specify the pipeline to use higher version of Nuget tool.
- task: NuGetToolInstaller#1
displayName: 'Use NuGet 6.0.0'
inputs:
versionSpec: 6.0.0
Fails to install workloads for MAUI for .NET 7 when running in azure dev ops. I was running the same pipeline in .NET 6 and it worked fine, but when I updated to .NET 7, it started failing to install the MAUI workload.
YAML
- task: UseDotNet#2
displayName: 'Use .NET Core sdk 7.x'
inputs:
version: 7.x
- task: DotNetCoreCLI#2
displayName: 'dotnet workload'
inputs:
command: custom
custom: 'workload '
arguments: 'install maui'
Logs
Installing pack Microsoft.Maui.Core.Ref.android version 7.0.0-rc.1.6430...
Workload installation failed. Rolling back installed packs...
Rolling back pack Microsoft.Maui.Core.Ref.android installation...
Workload installation failed: Unable to load the service index for source https://nuget.telerik.com/v3/index.json.
##[debug]Exit code 1 received from tool 'C:\hostedtoolcache\windows\dotnet\dotnet.exe'
##[debug]STDIO streams have closed for tool 'C:\hostedtoolcache\windows\dotnet\dotnet.exe'
##[error]Error: The process 'C:\hostedtoolcache\windows\dotnet\dotnet.exe' failed with exit code 1
##[debug]Processed: ##vso[task.issue type=error;]Error: The process 'C:\hostedtoolcache\windows\dotnet\dotnet.exe' failed with exit code 1
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://docs.microsoft.com/en-us/dotnet/core/tools/ and https://docs.microsoft.com/en-us/dotnet/core/compatibility/ . To learn about more such changes and troubleshoot, refer here: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#troubleshooting
##[debug]task result: Failed
##[error]Dotnet command failed with non-zero exit code on the following projects :
##[debug]Processed: ##vso[task.issue type=error;]Dotnet command failed with non-zero exit code on the following projects :
##[debug]Processed: ##vso[task.complete result=Failed;]Dotnet command failed with non-zero exit code on the following projects :
Finishing: dotnet workload
Comments
It is strange that is trying to install the MAUI workload 7.0.0-rc.1.6430 even though I am using the latest .NET 7 and not the release candidate.
This exact pipeline was working with .NET 6
I was able to fix this by specifying the --source on the command. I think me having external nuget sources for private feeds was interfering with it selecting the correct workload version somehow.
- task: DotNetCoreCLI#2
displayName: 'dotnet workload'
inputs:
command: custom
custom: 'workload '
arguments: 'install maui --source https://api.nuget.org/v3/index.json'
Installing pack Microsoft.Maui.Core.Ref.android version 7.0.0-rc.1.6430..
When you run the dotnet workload install maui, it will install maui according to the .net SDK version specified in global.json file firstly.
When you have a global.json file in your project, it will keep the version specified in the file even if you install the latest .NET 7 in the Pipeline.
To solve this issue, you can modify the global.json file and define the .net version(7.0.100).
For example:
{
"sdk": {
"allowPrerelease": true,
"rollForward": "disable",
"version": "7.0.100"
}
}
You can disable the rollForward in global.json file. Then it will not automatically upgrade the dotnet version of the project.
When you run the pipeline with the global.json above, it will use the version: Microsoft.Maui.Core.Ref.android version 7.0.49. This is the latest version of Maui.
Result:
I try to pack and publish a package as prelease on VSTS.
In the build step: dotnet (2* preview) pack I set a custom build number:
Automatic package versioning: use the build number.
Options:
$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)-alpha
It seems to build correctly:
Build #aspcore-repository (sqlserver)_2018.1.29.5-alpha has been
queued.
But in the pack step it loses the -alpha in the version and it is not published as a prelease package:
[command]"C:\Program Files\dotnet\dotnet.exe" pack
d:\a\1\s\SqlServer\Citolab.Repository.SqlServer.csproj --output
d:\a\1\a /p:PackageVersion=2018.1.29.3 --verbosity Detailed
What should I do to publish the package as prelease version?
This is a bug/feature of using the BuildNumber as your version source. I've submitted a pull request, but it hasn't been taken into the Nuget tasks yet. as a workaround use Environment Variable instead of Build Number and set the value to: BUILD_BUILDNUMBER.
I'm trying to set up CI for my Core projects and wrappers to our vsts nuget feed.
I've followed the Zen of Package Management tutorial here.
It's a little out of date, but I believe I managed to translate the changes.
My Build seems to work fine, it builds and packages the dll's into several nuget packages.
The release seems to work also, but the Nuget Feed is not updated with the latest packages.
My Release task is only one task as shown in the image below.
The log shows that it found and downloaded the packages, but it does not show any success on the actual push to nuget.
This is the log that shows the packages being found, and successful completion.
2017-11-15T02:40:59.5675003Z ##[section]Finishing: Initialize Job
2017-11-15T02:40:59.6125167Z ##[section]Starting: Download Artifacts
2017-11-15T02:41:00.2861639Z Downloading artifact
2017-11-15T02:41:00.2961643Z Creating artifacts directory: d:\a\r1\a
...etc
2017-11-15T02:41:00.8313684Z Downloading file d:\a\r1\a\Satalyst-Visual Studio-CI\drop\release\Packaged\Satalyst.AzureWrapper.Domain.2.0.0.3.nupkg
2017-11-15T02:41:00.9943663Z Downloading file d:\a\r1\a\Satalyst-Visual Studio-CI\drop\release\Packaged\Satalyst.PaymentGateway.Interfaces.2.0.0.3.nupkg
2017-11-15T02:41:00.9998063Z Downloading file d:\a\r1\a\Satalyst-Visual Studio-CI\drop\release\Packaged\Satalyst.PaymentGateway.Test.2.0.0.3.nupkg
...etc
2017-11-15T02:41:01.0750176Z Download complete.
2017-11-15T02:41:01.0761342Z 16 placed file(s): 16 downloaded, 0 empty
2017-11-15T02:41:01.0830178Z 1 MB downloaded at 1491 KB/sec. Download time: 00:00:00.2761869.
2017-11-15T02:41:01.0830178Z Downloaded linked artifact Satalyst-Visual Studio-CI
2017-11-15T02:41:01.0830178Z Finished artifacts download
2017-11-15T02:41:01.0890187Z ##[section]Finishing: Download Artifacts
... its this bit below that succeeds, but the feed does not show the new packages??
2017-11-15T02:41:01.0920188Z ##[section]Starting: NuGet Publish
2017-11-15T02:41:01.1190170Z ==============================================================================
2017-11-15T02:41:01.1190170Z Task : NuGet
2017-11-15T02:41:01.1190170Z Description : Restore, pack, or push NuGet packages, or run a NuGet command. Supports NuGet.org and authenticated feeds like Package Management and MyGet. Uses NuGet.exe and works with .NET Framework apps. For .NET Core and .NET Standard apps, use the .NET Core task.
2017-11-15T02:41:01.1190170Z Version : 2.0.15
2017-11-15T02:41:01.1190170Z Author : Microsoft Corporation
2017-11-15T02:41:01.1190170Z Help : [More Information](https://go.microsoft.com/fwlink/?LinkID=613747)
2017-11-15T02:41:01.1190170Z ==============================================================================
2017-11-15T02:41:04.1372760Z Caching tool: NuGet 4.1.0 x64
2017-11-15T02:41:04.1502760Z Found tool in cache: NuGet 4.1.0 x64
2017-11-15T02:41:04.1612765Z Resolved from tool cache: 4.1.0
2017-11-15T02:41:04.1612765Z Using version: 4.1.0
2017-11-15T02:41:04.1612765Z Found tool in cache: NuGet 4.1.0 x64
2017-11-15T02:41:05.1667858Z [command]C:\Windows\system32\chcp.com 65001
2017-11-15T02:41:05.1667858Z Active code page: 65001
2017-11-15T02:41:05.1877908Z ##[section]Finishing: NuGet Publish
2017-11-15T02:41:05.1937859Z ##[section]Finishing: Release
Any assistance would be greatly appreciated, I've been doing a bit of trial and error to find the issue with no success. I'm now a bit stuck with no error messages and no feedback on the outcome for the push.
It's caused by the configuration of Path to NuGet package(s) to publish option for NuGet Push task in your release definition.
Please change the Path to NuGet package(s) to publish as:
$(System.DefaultWorkingDirectory)/**/packed/*.nupkg
Then the nuget package should be published to your feed correctly.
I have a Build definition in Team Services that includes a Nuget Packager task. I'm using Hosted build agents.In the last couple of builds this task began to fail, with the following message:
2017-02-22T21:43:24.9318762Z C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\2.112.0\externals\nuget\NuGet.exe pack "D:\a\1\s\src\app\Ormie\Ormie.csproj" -OutputDirectory "D:\a\1\s" -Properties Configuration=release
2017-02-22T21:43:25.5460318Z MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
2017-02-22T21:43:25.5460318Z Attempting to build package from 'Ormie.csproj'.
2017-02-22T21:43:25.7480272Z Packing files from 'D:\a\1\s\src\app\Ormie\bin\Release'.
2017-02-22T21:43:25.9040273Z Using 'Ormie.nuspec' for metadata.
2017-02-22T21:43:26.1645370Z ##[error]'System.Collections' already has a dependency defined for 'Microsoft.NETCore.Platforms'.
2017-02-22T21:43:26.1865365Z ##[error]System.Exception: Unexpected exit code 1 returned from tool NuGet.exe
2017-02-22T21:43:26.1865365Z at Microsoft.TeamFoundation.DistributedTask.Task.Internal.InvokeToolCmdlet.ProcessRecord()
2017-02-22T21:43:26.1865365Z at System.Management.Automation.CommandProcessor.ProcessRecord()
2017-02-22T21:43:26.2015355Z ##[error]PowerShell script completed with 1 errors.
2017-02-22T21:43:26.2025352Z ##[section]Finishing: NuGet Packager
In order to understand what was happening, I tried to create the package in my development box, using NuGet version 3.3, and got a similar message. So, I've updated NuGet to version 3.5, tried to pack in my machine and it worked just fine.So, my questions are:
Is there any kind of configuration in Team Services Build Definition
that can be done to solve this issue?
How can I force the Hosted build agent to use version 3.5 in the
NuGet Packager task?
To use nuget3.5 for nugget packager task, you can add nugget.exe to source control, and then use $(Build.SourcesDirectory)\nuget.exe as path to nugget.exe.
For Nuget Restore and Nuget Publisher Tasks, they define 3.3 and 3.5 in their tasks. You can view task.json for all tasks definitions in VSTS task.
If you want Nuget Packager also can choose nugget version, you should develop your own task same as Nuget Packager function and with nuget version to choose.