DotNetCLI#2 pack seems to be ignoring configuration inputs - azure-devops

The below YAML snippet does not seem to work as expected.
I configured it in a pipeline that runs using the windows-latest image and it attempts to restore all of the projects that are in the repo, instead of looking just to the solution file.
Also, it seems to completely ignore the --no-restore flag
- task: DotNetCoreCLI#2
displayName: Package to Staging directory
inputs:
command: pack
configuration: $(BUILD_CONFIGURATION)
projects: 'support-libs.sln'
packDirectory: $(Build.ArtifactStagingDirectory)
nugetConfigPath: 'sf-solution/nuget.config'
arguments: '--no-restore'
verbosityRestore: Minimal
The command that appears on the step logs is:
"C:\Program Files\dotnet\dotnet.exe" pack
d:\a\1\s\sf-solution\SampleProject\SampleProject.csproj --output
d:\a\1\a /p:Configuration=Debug --verbosity Detailed
The above project is not even included in the support-libs SLN file the snippet has configured.

The above project is not even included in the support-libs SLN file the snippet has configured
Not sure why DotNetCLI task pack the project, which is not included in in the support-libs SLN. Since you did not share your project file structure and the build log in your question, I could not give you the directly reason for this issue.
But as workaround, you could specify the specific project file instead of the solution file. Besides, you can also check this task by classic editor:
It state the path to csproj or nuspec file(s) to pack.
For the ignoring configuration inputs problem, there is an option Do Not build, so, you could add this argument to your pack task instead of the argument --no-restore:
- task: DotNetCoreCLI#2
displayName: 'dotnet pack'
inputs:
command: pack
packagesToPack: YourProjectPath&Name.csproj
nobuild: true
Note: Add a DotNet build task before you use this pack task.
Hope this helps.

I was finally able to do what I wanted and to pack all the libraries inside the solution, however I had to use a custom command instead of the pack one:
- task: DotNetCoreCLI#2
displayName: Package to Staging directory
inputs:
command: custom
custom: 'pack'
arguments: 'support-libs.sln -c=$(BUILD_CONFIGURATION) -o $(Build.ArtifactStagingDirectory)'
verbosityRestore: Minimal
verbosityPack: Minimal
feedsToUse: select
vstsFeed: personalnugetfeed
nuGetFeedType: internal
includeNuGetOrg: true
I was also having authorization issues with the internal feed that was in the Nuget configuration and linking to that file, even from a custom command, had the same issues.
Explicitly stating from which feed the restore should be made worked perfectly and I was able to retrieve all the dependencies removing the need to use the --no-restore flag.

Related

DotNetCoreCLI#2 / pack in Azure DevOps pipeline is looking for files in the wrong subfolder

TL;DR
I'm building a nuget package with Azure Devops pipelines, and the DotNetCoreCLI#2 / pack command is looking for the built assemblies and other files of dependent projects in the wrong folder because the name of the solution configuration the yaml uses is different from the name of the build configuration of the dependent projects the solution configuration uses.
In detail:
The project dependencies in the solution: Main --> DepA --> DepB.
The nuget package is built from Main.
The yaml uses a solution configuration called ReleaseMain, which ...
builds only the above projects
uses the Release build configuration of each project. I can't see any point in creating a separate build configuration called ReleaseMain in each project if Release can be referred to by ReleaseMain.
The relevant parts of the yaml:
variables:
buildConfiguration: 'ReleaseMain'
steps:
- task: NuGetToolInstaller#1
- task: DotNetCoreCLI#2
inputs:
command: 'restore'
projects: '**/Main.csproj'
feedsToUse: 'select'
vstsFeed: '<nuget feed ID>'
# I don't use a DotnetCoreCLI#2 / Build task because the pack command also builds everything it needs. This works with other pipelines.
- task: DotNetCoreCLI#2
inputs:
command: 'pack'
packagesToPack: '**/Main.csproj'
versioningScheme: 'off'
The pack task fails while building the DepB project because it is looking for obj\ReleaseMain\netstandard2.0\.NETStandard,Version=v2.0.AssemblyAttributes.cs but doesn't find it, since it is in the obj\Release\netstandard2.0\ folder. Then the log contains the same error for the DepA project, and the task fails.
So the problem is that the pack command is looking for release files in a subfolder named after the solution configuration instead of the build configuration of the projects.
In cases when the project from which the nuget package is built has no project dependencies, I can make the pipeline work by specifying the project build configuration name in the files/file XML elements of the nuspec file, see below.
<files>
<!-- instead of this -->
<file src="bin\$configuration$\netcoreapp3.1\Main.dll" target="lib\.NETCoreApp3.1" />
<!-- I hardcode this -->
<file src="bin\release\netcoreapp3.1\Main.dll" target="lib\.NETCoreApp3.1" />
</files>
But the build task is stuck before this step in the above scenario, so I only mention this as a side note.
There must be a solution for this because it seems a pretty frequent situation to me but I can't find it. I know I could create a project build configuration called ReleaseMain for each project but it seems unnecessary. Or is the way the nuget pack command works incompatible with this setup?

msbuild /t:metrics fails on azuredevops pipeline

While running below command for the solution it works fine on command line on on-premise.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\msbuild.exe" test.sln /t:Metrics -p:Configuration=Debug -p:Platform="Any CPU"
The task used in the pipeline is :
- task: CmdLine#2
inputs:
script: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\msbuild.exe" Test.sln /p:AzureDevOps=true /verbosity:d /t:Metrics -p:Configuration=Debug -p:Platform="Any CPU"'
workingDirectory: 'C:\a\1\s\Ett\Test'
failOnStderr: true
Also tried the task :
- task: VSBuild#1
displayName: CodeMetrics
inputs:
solution: '**\CN.Test.sln'
msbuildArgs: '/t:Metrics'
platform: 'Any CPU'
configuration: 'debug'
createLogFile: true
logFileVerbosity: 'detailed'
However fails to run from the pipeline with below error :
The target "Metrics" does not exist in the project
The target 'Metrics' the nuget 'Microsoft.CodeAnalysis.Metrics' is installed in each project.
This is the key. That target won't be available until after you've restored the nuget packages. The packages will have been restored on your local machine though.
For your build pipeline to work make sure you perform a restore first, either as part of the existing invocation of MSBuild, or as a seperate step.
MSBuild /t:restore;metrics ...
Or:
Msbuild /t:restore ...
Msbuild /t:metrics ...
Based on your description and concern, in your second shared task, for msbuildArgs: '/t:Metrics' in the task, the specified target File structure '/t:Metrics' is not completed, that's why you met this issue.
To solve this issue, you could define the target to folder level where the spevified csproj file located.
For example: File structure: xx->xxx->metrics ->xx.csproj
msbuildArgs: ”/t:xx\xxx\metrics“
For more information, you could also refer to the doc: How to: Build specific targets in solutions by using MSBuild.exe .

Azure Function Build Pipelines Fails when Unit Test Project references the Function project

I am using Visual Studio 2019 Community Edition and I have a multi-tier solution. Below is a screenshot of that.
Please note, it's a sample project to replicate a production solution, so, namings probably are not really important here.
Project specifications: (all netcoreapp3.1)
Sample.AzureFunction.Api - Target Framework: netcoreapp3.1and Azure Function version: 3.0.7
{ Application, Model, ClassLibrary1, and ClassLibrary2 } - Target Framework: netcoreapp3.1 and all are `.netcore class library' projects.
ApiTests - Target Framework: netcoreapp3.1
The Problem
The Azure Build Pipeline fails when there is a reference from the ApiTest project to the Sample.AzureFunction.Api. If I remove the project reference, the build continues to be green. Here is a screenshot from the build errors when the build step is running in the pipeline.
Basically, all the errors are complaining about not finding some dlls. For example, CSC : error CS0006: Metadata file 'D:\a\1\s\publish_output\Application.dll' could not be found [D:\a\1\s\Sample.AzureFunction.Api\Tests\ApiTests\ApiTests.csproj]
Few Notes:
The build step in the pipeline is .net core added automatically by Azure DevOps.
I don't have a dedicated Agent and I use the Azure Pipelines that comes by default when creating a new CI.
Agent specification is windows-2019
I used the classic view to create the pipeline (no YAML) but I could grab the following YAML from the generated steps by clicking on each of them and copying the YAML:
I've spent a day on resolving this issue and I'm running out of ideas now. Any thoughts would be appreciated.
If you remove --output argument your build will succeeded.
It looks like your folder publish_output was cleared before compiling test project. Thus it can't find these dlls there.
Furthermore, you don't need rather to publish as an artifact all dlls. Please use publish command to create artifact for code which is going to be deployed:
- task: DotNetCoreCLI#2
inputs:
command: publish
publishWebProjects: True
arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
zipAfterPublish: True
# this code takes all the files in $(Build.ArtifactStagingDirectory) and uploads them as an artifact of your build.
- task: PublishBuildArtifacts#1
inputs:
pathtoPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: 'myWebsiteName'
I listed publish_output folder after running your original pipeline and you can find there these files:
Application.deps.json
ClassLibrary1.deps.json
Function1
Sample.AzureFunction.Api.deps.json
bin
host.json

VSTS YAML Build publishing strange path

I'm publishing build artefacts from $(Build.Repository.LocalPath)/src/cookiecutter.utility.tool.csproj and setting an output path of $(build.artifactstagingdirectory)/dist, however for some reason I can't comprehend it's adding the src element to the output path, rather than just dist.
I've checked the YAML docs and can't see anything that would suggest I've done something wrong.
The YAML section
task: DotNetCoreCLI#2
displayName: Publish
inputs:
command: publish
publishWebProjects: false
zipAfterPublish: false
projects: $(projectDir)/cookiecutter.utility.tool.csproj
arguments: '--configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory) --self-contained -r win10-x64 /p:PublishSingleFile=true /p:PublishTrimmed=true
'
View of source repo.
Because you specify the projects in the dotnet publish task.
This .csproj is what you are trying to publish. When you specify the exactly project file value to task parameter projects , at this time, the output path is in project file’s directory rather than the root directory. That's why it keep the path of src in the artifact path.
If you don't want this src displayed, just remove projects: $(projectDir)/cookiecutter.utility.tool.csproj . Then the publish will work with the root directory(all projects) and the src will not displayed any more.
Update:
As I mentioned in my comment, as normal, it will looking for project file automatically under its working directory during dotnet.exe execution. For VSTS, the default working directory is solution folder (root).
So, to work around the Specify a project or solution file error and avoid the strange path added in artifact also, you can configure yourself working directory by using workingDirectory: src.
- task: DotNetCoreCLI#2
displayName: Publish
inputs:
command: publish
publishWebProjects: false
arguments: '--configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory) --self-contained -r win10-x64 /p:PublishSingleFile=true /p:PublishTrimmed=true'
zipAfterPublish: false
modifyOutputPath: true
workingDirectory: src
This could let you avoid the src display in artifact structure without error.

VSTS Yaml vraiables and path contradicting with classic editor

I am facing an issue when setting VSTS classic editor parameters when compare with current yaml file which is working as expected.
Below is working fine (Build pipeline)
- task: CopyFiles#2
displayName: "Copy Files to: $(Build.ArtifactStagingDirectory)"
inputs:
contents: '$(Build.SourcesDirectory)/src/xxx.EndToEnd.Integration.Tests/**'
targetFolder: $(Build.ArtifactStagingDirectory)
- task: DotNetCoreCLI#2
displayName: "dotnet e2e tests"
inputs:
command: publish
publishWebProjects: false
projects: '**/*.csproj'
arguments: --output $(Build.ArtifactStagingDirectory)/src/xxx.EndToEnd.Integration.Tests
zipAfterPublish: false
But same setting as per below find 0 files
2019-04-06T10:02:57.5303667Z found 0 files
2019-04-06T10:02:57.5376614Z ##[section]Finishing: Copy Files to: $(Build.ArtifactStagingDirectory)
I have changed the / to \ as well, but same outcome.
Below is designer pipeline
Same results in dotnet publish task also in Path to project(s) parameter **\**\*.csprojgives below error, but above yaml file works as expected.
2019-04-06T10:02:58.7896707Z ##[error]Project file(s) matching the specified pattern were not found.
In the release pipeline the variables Build.SorucesDirectory and Build.ArtifactSatgingDirectory are not available, these variables are only for build pipelines.
In fact, in the release agent folder there is not "Soruces" folder, but only "Artifact" folder. for example: C:\agent\_work\r1\a, the variable to get the value is: System.ArtifactDirectory or Agent.ReleaseDirectory.
More details about release variables you can find here.