I'm trying to test my .NET Core 5.0 projects in my Azure DevOps pipeline. When using a full path to one of my test projects the pipeline will test that single project. When using a pattern to search for all my test projects he can't find one of them.
My project structure is as follows:
backend
DemoProject (with the .sln file)
DemoProject.Application
DemoProject.Application.Test
DemoProject.Persistance
DemoProject.Persistance.Test
DemoProject 2
....
To find a solution I created a simple version of my pipeline template:
- master
pool:
vmImage: ubuntu-latest
steps:
- task: DotNetCoreCLI#2
inputs:
command: 'test'
projects: './backend/DemoProject/DemoProject.Application.Tests/DemoProject.Application.Tests.csproj'
When using the full path (./backend/DemoProject/DemoProject.Application.Tests/DemoProject.Application.Tests.csproj), the pipeline find's the selected project. When using a pattern (./backend/DemoProject/\*\*/\*.Tests.csproj or ./backend/DemoProject/\*\*/DemoProject.Application.Tests.csproj), the pipeline can't find any project.
Does someone knows what the correct pattern is to run all my test projects inside the DemoProject folder?
Try **/*.Test.csproj, I have used it in projects with more complex folder structures without any issues.
- task: DotNetCoreCLI#2
inputs:
command: test
arguments: --configuration Release
projects: '**/*.Test.csproj'
workingDirectory: './backend/DemoProject/'
Related
I have a .net core 3.0 azure function project in an existing solution. While it builds and runs fine in visual studio, the CDPX for it sometimes failed with message-
MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 1, position 1
The YAML being used-
steps:
- task: DotNetCoreCLI#2
displayName: 'dotnet core test'
inputs:
command: test
projects: '**\*ProjectDllName.dll'
Running the same build again fixes the issue. But this is happening very frequently now.
Im trying to pack a web api i made in .net core 3.1 with Azure Pipeline.
- task: DotNetCoreCLI#2
displayName: Package NuGet
inputs:
command: 'pack'
projects: '**/*.csproj'
arguments: '--configuration $(BuildConfiguration)'
outputDir: '$(Build.ArtifactStagingDirectory)/packages'
Thats the task i used, i found it from another post on stack overflow.
My only issue with that is that it gives a number of .nupkg files, instead of one, and that the web api packages doesn't have the dependencies dll.
Also i created a .nuspec file, but i don't seem to manage to use it correctly with Azure Pipeline
I've tried what's explained here : https://learn.microsoft.com/fr-fr/nuget/reference/msbuild-targets#packing-using-a-nuspec
or just by targeting the .nuspec file like it is explained on the tooltipe of pipeline
If anybody could put me on the right path that would be greatly appreciated :)
EDIT:
I want to pack everything in a nupkg to then deploy it for an IIS site.
This is my nuspec file :
<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<id>WebAPI</id>
<version>1.0.0</version>
<authors>Kevin Pinero</authors>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>WebAPI</description>
</metadata>
<files>
<file src=".\bin\Release\*\*.dll" target="lib" />
<file src=".\bin\Release\*\*.exe" target="lib" />
<file src=".\bin\Release\*\*.json" target="lib" />
<!-- <file src=".\bin\Release\*\Properties\*.json" target="lib" /> -->
<file src=".\bin\Release\*\*.pdb" target="lib" />
<file src=".\bin\Release\*\*.config" target="lib" />
</files>
</package>
And this the error i get on the pipeline :
error MSB4068: The element is unrecognized, or not supported
in this context.
Using this task :
- task: DotNetCoreCLI#2
inputs:
command: 'pack'
packagesToPack: '**/*API.nuspec'
nobuild: true
versioningScheme: 'off'
I know on microsoft website I could potentially use this command too
dotnet pack ~/projects/app1/project.csproj -p:NuspecFile=~/projects/app1/project.nuspec -p:NuspecBasePath=~/projects/app1/nuget
But i'm not sure how to translate it in AZ pipeline ...
EDIT Solution adopted:
I've decide to resolve my issues this way :
- task: DotNetCoreCLI#2
displayName: Build at solution level
inputs:
command: 'build'
projects: $(solution)
arguments: '--no-restore --configuration $(buildConfiguration)'
- task: DotNetCoreCLI#2
displayName: Execute tests
inputs:
command: 'test'
projects: $(testProjects)
arguments: '--no-build --configuration $(buildConfiguration)'
- task: DotNetCoreCLI#2
displayName: Pack project
inputs:
command: publish
projects: '**/projectName.csproj'
publishWebProjects: False
arguments: '--no-build --configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)
zipAfterPublish: False
- task: PublishBuildArtifacts#1
displayName: Publish
inputs:
pathtoPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: 'artefact name'
I would recommend to use the Azure DevOps online pipeline editor. It is great to use and get up to speed (auto-completion, syntaxic review, direct commit/push).
What you try to achieve can be done with the steps:
dotnet build
dotnet pack -> specify the right projects to be packed here
- task: DotNetCoreCLI#2
displayName: 'Create packed NuGet files'
inputs:
command: 'pack'
packagesToPack: '**/*Api.csproj;!**/*Tests.csproj'
versioningScheme: 'off'
nuget push
No need for a nuspec file as long as you add some fields in your csproj.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.1</TargetFramework>
<AssemblyName>Withywoods.Selenium</AssemblyName>
<RootNamespace>Withywoods.Selenium</RootNamespace>
<ProjectGuid>{08D9DDB8-BF5B-4E45-8E0C-D9AC85ABF020}</ProjectGuid>
<Authors>devprofr</Authors>
<Description>Library to ease the use of Selenium web driver and provide testing best practices.</Description>
<RepositoryUrl>https://github.com/devpro/withywoods</RepositoryUrl>
<PackageProjectUrl>https://github.com/devpro/withywoods</PackageProjectUrl>
</PropertyGroup>
I have a short example here if you want: pkg.yml
.NET Core and Azure DevOps is a great combination, feel free to comment if you have any issues!
(On my side, I pack library projects but not Api, I do dotnet publish on Api to use them as artifact in release pipelines.)
My only issue with that is that it gives a number of .nupkg files,
instead of one, and that the web api packages doesn't have the
dependencies dll.
I assume you have more than one projects in same solution. Let's call the Web Api project A, other projects B, C and D...
1.So if you only want to pack A into nuget package, instead of using projects: '**/*.csproj', we can use something like projects: '**/A.csproj'. Then it won't pack a number of nuget packages any more.
2.For the dependencies dll, I think you mean the project references like Josh Gust said above. For this, it's still one open issue about dotnet pack command. You can track that issue there to get notifications if there's any update.
For now, we have to make changes to A.csproj to use msbuild magics as workaround. You can try Martin's or zvirja's workarounds there. In my opinion, they both helps for your issue.
Hope all above helps :)
Update1:
For your edit, if you want to translate it in AZ pipeline, you can use the custom command to call the pack. Something like this:
- task: DotNetCoreCLI#2
displayName: 'dotnet custom'
inputs:
command: custom
projects: '**/ProjectName.csproj'
custom: pack
arguments: '-p:NuspecFile=~/projects/app1/project.nuspec -p:NuspecBasePath=~/projects/app1/nuget'
You can check the log to confirm it actually ran the command: "C:\Program Files\dotnet\dotnet.exe" pack D:\a\1\s\xxx\xxx.csproj -p:NuspecFile=~/projects/app1/project.nuspec -p:NuspecBasePath=~/projects/app1/nuget. Hope that's what you need.
And I'm not certainly sure that we can use ~ in that command, but if it works locally, then you can translate it in Azure Devops Pipeline using my way...
UPDATE
Because you are trying to package a Web API project for delivery to IIS, you should stop trying to use nuget as that mechanism, and instead use the dotnet publish command. If you want to continue to use the DotNetCoreCLI#2 task (as opposed to using the script shortcut to call the dotnet cli directly), then I would point you to the documentation to Build, Test and Deploy .Net Core Apps.
This documentation is not written specifically for Web API projects, but is a set of generic guidelines for operating with .Net Core Apps is Azure DevOps Pipelines. An example is quoted below (emphasis mine):
After you've built and tested your app (not web api specifically), you can upload the build output to Azure Pipelines or TFS, create and publish a NuGet package, or package the build output into a .zip file to be deployed to a web application.
When you read in the Package and Deliver your Code section that publish to a NuGet feed is a valid option for delivering code, it is. However this method of delivery should be used for library type deliverables. The dotnet publish command is what is designed to package a web api project and all its dependencies into a .zip (or folder if you specify that option) in preparation for Web Deploy commands against an IIS instance.
Original Answer
Without getting into the details of why you want to create a .nupkg from your API project.
You mention:
My only issue with that is that it gives a number of .nupkg files, instead of one, and that the web api packages doesn't have the dependencies dll
This has been the MO of dotnet pack for a while now as regards project-to-project (P2P) references.
The documentation for dotnet pack states this behavior.
NuGet dependencies of the packed project are added to the .nuspec file, so they're properly resolved when the package is installed. Project-to-project references aren't packaged inside the project. Currently, you must have a package per project if you have project-to-project dependencies.
If you want to have more control over the files that are included in your .nupkg then you will want to author a .nuspec file manually and provide it to the dotnet pack command as indicated in the last Example on the documentation page.
Using the Azure DevOps task for the dotnet core cli DotNetCoreCLI#2 should allow you to simply put the path to the .nuspec file in the input. More information will be necessary in your question if this isn't working for you.
I have a simple solution that have two projects in it and I want it go through the azure build pipeline. One project is pure class files that will get build a DLL but that code is not the GIT repo in the same folder. And the other project is ASP.NET project and I have configured that in the pipeline. When I am trying to build the project it is giving me an error as below:
MSBUILD : error MSB1011: Specify which project or solution file to use
because this folder contains more than one project or solution file.
[error]Cmd.exe exited with code '1'.
Yaml File
# ASP.NET Core
# Build and test ASP.NET Core projects targeting .NET Core.
# Add steps that run tests, create a NuGet package, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/dotnet-core
trigger:
- master
pool:
name: 'buildserver'
variables:
buildConfiguration: 'Release'
steps:
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
The error is asking you to identify the .sln or .csproj (or other proj type) file b/c dotnet doesn't know what you want it to do.
I tend to use variables for this kind of thing because I'm often using the solution name in other tasks.
example:
trigger:
- master
pool:
name: 'buildserver'
variables:
buildConfiguration: 'Release'
slnName: 'mySol'
solution: 'some/dir/$(slnName).sln'
steps:
- script: dotnet build $(solution) --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
.csproj example:
With a repository (and solution) structure as follows:
(this is the part of your question that remains unclear)
myRepo
|--.git
|--src
|--proj1
| |--proj1.csproj
|
|--proj2
| |--proj2.csproj
|
|--mySol.sln
You would simply call out the .csproj file you want the pipeline to build.
trigger:
- master
pool:
name: 'buildserver'
variables:
buildConfiguration: 'Release'
projName: 'proj1'
project: 'src/$(projName)/$(projName).csproj'
steps:
- script: dotnet build $(project) --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
With the above examples you shouldn't need to specify the .sln or .csproj as each potential build target lives in its own directory, and the dotnet cli searches from $pwd if you don't give it a value. Therefore, if your pipeline is working in the root of the repo (default behavior), dotnet should find the .sln file first and build it.
However
If your directory structure looks like the following, then you would need to specify:
myRepo
|--.git
|--src
|--proj1.csproj
|--class1.cs
|--class2.cs
|--proj2
| |--proj2.csproj
| |--class1.cs
|
|--mySol.sln
In the above dotnet doesn't know whether you want to build mySol.sln or proj1.csproj, so indicating the file to build should solve your problem, but I might suggest that you restructure your repository.
If proj2 doesn't make its home in myRepo
And is a dependency of proj1 then you will need to do some other acrobatics (ie: manual git repo clone) in the pipeline to get that project and it's files where they need to be. If this is the case, I would strongly suggest you treat proj2 as a completely independent product and deliver it to those projects (proj1) that depend upon it via NuGet or other package delivery method.
I am trying to add Code Coverage results in an Azure DevOps build for a .NET Core project, but, trying two different approaches based on this guide on MSDN:
Currently, after building the solution, I have a dotnet step for test, collecting the Code Coverage and publishing those results. I also tryed disabling this check for publishg, and adding a command line step and a Publish Test Results.
Here the screenshot and yaml for the test step:
- task: DotNetCoreCLI#2
displayName: 'Test solution'
inputs:
command: test
projects: '**/*Test/*.csproj'
arguments: '--configuration $(buildConfiguration) --collect "Code coverage"'
workingDirectory: ChustaSoft.Common.UnitTest
And here the screenshots and yaml for the currently disabled steps:
- script: 'dotnet test ChustaSoft.Common.UnitTest --logger trx --collect "Code coverage"'
displayName: 'Command Line Script'
enabled: false
- task: PublishTestResults#2
displayName: 'Publish Test Results'
inputs:
testResultsFormat: VSTest
testResultsFiles: '**/*.trx'
enabled: false
With both approaches, I could see Test results, but not the Code Coverage, here is an screenshot of what I am able to see it:
Any idea? I am missing something? How can I see the Code Coverage when the build is finished?
Thank you a lot in advance,
PD: Project is multitarget: .NET Core 2.0, .NET Standard 2.0 and .NET 4.6.1, UnitTest project is a .NET Core MSTest project
EDIT: Added Test step output:
Try to run the tests with adding first
Visual Studio Test Platform Installer Task
then
Visual Studio Test -->>Test assemblies Task
Remove the Publish Test and the Command line Tasks.
I am having trouble configuring an Azure DevOps Dotnet core build process.
I have a simple dotnet core project which I am attempting to build in an Azure DevOps environment.
The project is in a subfolder within my repo, but I cannot figure out how to specify how the Pipeline should find my csproj file. The MSDN documentation suggests that you can specify it but there are no examples and all of my attempts are met with errors.
When building a pipeline with the standard dotnet CLI template, the YAML created is:
# ASP.NET Core
# Build and test ASP.NET Core web applications targeting .NET Core.
# Add steps that run tests, create a NuGet package, deploy, and more:
# https://learn.microsoft.com/vsts/pipelines/languages/dotnet-core
pool:
vmImage: 'Ubuntu 16.04'
variables:
buildConfiguration: 'Release'
steps:
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
However this is met with the error:
MSBUILD : error MSB1003: Specify a project or solution file.
The current working directory does not contain a project or solution file.
The documentation linked above suggests using a "task" based syntax rather than a script, and I assume that in the documentation the inputs are listed in the same order as the examples listed underneath.
If you use the script you specify the csproj file after the build word:
- script: dotnet build myrepo/test/test.csproj --configuration $(buildConfiguration)
The best way to use Azure DevOps Pipeline is to use tasks for the build pipeline, in the Dotnet Core yaml build task you specify the file in the inputs section:
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: 'myrepo/test/test.csproj'