I have problems to get my gtest runing in my build pipeline. My solution works well to build and run test case in Visual Studio 2017. On the DevOps environment I use .Net Desktop setup with minor modification. The build task work fine as well in pipeline.
I try use default VSTest task, but I'm not sure it right task for run Google Test that is create with Visual Studio project from VS IDE.
Build pipline yml script
# .NET Desktop
trigger:
- master
# Install build environment
pool:
vmImage: 'windows-latest'
name: Hosted VS2017
variables:
solution: '**/*.sln'
buildPlatform: 'x86'
buildConfiguration: 'Debug'
steps:
- task: NuGetCommand#2
inputs:
restoreSolution: '$(solution)'
# Build VS solutions including gtest project.
- task: VSBuild#1
inputs:
solution: '$(solution)'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
# Run gTest, this task not working see log below.
- task: VSTest#2
inputs:
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
VSTest log output
Running tests using vstest.console.exe runner.
======================================================
Test selector : Test assemblies
Test filter criteria : null
Search folder : d:\a\1\s
VisualStudio version selected for test execution : latest
Attempting to find vstest.console from a visual studio installation with version [16.0,17.0).
Attempting to find vstest.console from a visual studio build tools installation with version [16.0,17.0).
Attempting to find vstest.console from a visual studio installation with version [15.0,16.0).
Run in parallel : false
Run in isolation : false
Path to custom adapters : null
Other console options : null
Code coverage enabled : false
Diagnostics enabled : false
SystemVssConnection exists true
Run the tests locally using vstest.console.exe
========================================================
##[warning]No test assemblies found matching the pattern: **\*test*.dll,!**\*TestAdapter.dll,!**\obj\**.
Yes, VSTest task which will use VSTest.Console.exe. It's able to run custom test adapters (like the Google Test Adapter).
However, after go through the build-in Included Software of Hosted VS2017 build agent, it's not listed. If so, you could use Self-hosted Windows agents.
You can download the Google Test Adapter as Visual Studio Extension, unzip it (rename .vsix file to .zip) and place that entire unzipped folder somewhere on your Build agent machine. The build step then has to point to that directory.
Additionally of course, your project should include the "googletest" NuGet package in order to run the tests.
If you still not able to get it work, please remote to build agent machine and manually run the build and test use visual studio or command line instead through Azure DevOps pipeline. This will narrow down if it's an environment issue.
Related
I have a build pipeline yaml file that looks like the following:
# ...
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Production 12'
# ...
- task: VSBuild#1
inputs:
solution: '$(solution)'
msbuildArgs: '/p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactStagingDirectory)\WebApp.zip"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
The Production 12|Any CPU configuration is supposed to be built.
But it is not, another one is (Test|Any CPU), as shown in the logs:
Starting: VSBuild
==============================================================================
Task : Visual Studio build
Description : Build with MSBuild and set the Visual Studio version property
Version : 1.199.0
Author : Microsoft Corporation
Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/build/visual-studio-build
==============================================================================
"D:\a\_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.199.0\ps_modules\MSBuildHelpers\vswhere.exe" -version [17.0,18.0) -latest -format json
"D:\a\_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.199.0\ps_modules\MSBuildHelpers\vswhere.exe" -version [17.0,18.0) -products Microsoft.VisualStudio.Product.BuildTools -latest -format json
"D:\a\_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.199.0\ps_modules\MSBuildHelpers\vswhere.exe" -version [16.0,17.0) -latest -format json
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\msbuild.exe" "D:\a\1\s\SafeProtect.sln" /nologo /nr:false /dl:CentralLogger,"D:\a\_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.199.0\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll";"RootDetailId=10c69004-b8fb-410e-ba0d-6d600dac481c|SolutionDir=D:\a\1\s|enableOrphanedProjectsLogs=true"*ForwardingLogger,"D:\a\_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.199.0\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll" /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="D:\a\1\a\WebApp.zip" /p:platform="Any CPU" /p:configuration="Test" /p:VisualStudioVersion="16.0" /p:_MSDeployUserAgent="VSTS_09716650-7645-4cc6-8318-3b574bba08b5_build_1_0"
Building the projects in this solution one at a time. To enable parallel build, please add the "-m" switch.
Build started 3/17/2022 12:36:04 PM.
Project "D:\a\1\s\SafeProtect.sln" on node 1 (default targets).
ValidateSolutionConfiguration:
Building solution configuration "Test|Any CPU".
What is happening ?
Azure Devops build pipelines : build configuration in Yaml file not used
First, try to check if you missing build configuration in the Configuration Properties with Visual Studio or the checkbox of build is not checked.
Right clicking the solution, selecting "Properties" and then looking at the "Configuration Properties" property sheet:
Second, try to build and deploy it on your local to check if you have this issue, if not, please check the MSBuild version (Visual Studio Version) and the .net framework version with the version on the Azure devops.
I solved the problem by recreating the build pipeline (.yml file).
So I guess that there is a glitch while processing the .yml file when it is modified to update the pipeline tasks.
I have a project that builds using the following frameworks:
<TargetFrameworks>netstandard2.0;netstandard2.1;net5.0</TargetFrameworks>
This compiles just fine on my local machine, but when I push it to Azure, it fails.
When I have the following in my YAML file:
variables:
solution: '**/*.sln'
buildConfiguration: 'Release'
buildPlatform: 'Any CPU'
platform: x64
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: '**/*.csproj'
arguments: '--configuration $(buildConfiguration)'
Then I get:
##[error]C:\Program Files\dotnet\sdk\3.1.403\Microsoft.Common.CurrentVersion.targets(1177,5):
Error MSB3644: The reference assemblies for .NETFramework,Version=v5.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
And if I try
- task: VSBuild#1
displayName: 'Build all'
inputs:
solution: '$(solution)'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
maximumCpuCount: true
I get:
##[error]C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1177,5):
Error MSB3644: The reference assemblies for .NETFramework,Version=v5.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
The developer packs documentation refer only to the older .Net Framework, so I suspect this is irrelevant/outdated.
This works fine if I change .Net 5 for .Net Core 3.1, i.e. <TargetFrameworks>netstandard2.0;netstandard2.1;netcoreapp3.1</TargetFrameworks>
The reason your project doesn't build successfully is because the Microsoft-Hosted agent doesn't have the.NET 5.0 SDK installed.
You can download the.NET 5.0 SDK using Use.NET Core Task:
- task: UseDotNet#2
inputs:
packageType: 'sdk'
Version: '{version}'
includePreviewVersions: {true/false}
This task can download a specific version of the .Net SDK from the network and add it to the PATH.
In addition, since you are using multiple versions of .NET in your project, you can use this task to specify which version of.NET you will use in the following tasks.
In other words, this task has two functions:
Download a specific SDK version that is not installed.
Specify which SDK version will be used for the following tasks.
I think there is a problem with build agent machines.
If you use cloud azure devops you need to wait when they will update their build machines.
If you use on premise azure devops try to update build machines by yourself.
I am trying to build a repository in Azure Pipelines. It builds OK in Visual Studio, but when using Azure Pipelines (with an agent running on a build machine), it fails with the following error:
The nuget command failed with exit code(1) and error
Project MyProject is not compatible with netcoreapp2.2 (.NETCoreApp,Version=v2.2).
Project MyProject supports: netstandard2.0 (.NETStandard,Version=v2.0)
How can I fix this?
And here is the yaml build script:
pool:
name: MyBuildServer
demands:
- msbuild
- visualstudio
steps:
- task: NuGetCommand#2
displayName: 'NuGet restore'
- task: VSBuild#1
displayName: 'Build solution **\*.sln'
- task: VSTest#2
displayName: 'Run tests'
inputs:
testSelector: 'testAssemblies'
testAssemblyVer2: |
**\*test*.dll
!**\*TestAdapter.dll
!**\obj\**
searchFolder: '$(System.DefaultWorkingDirectory)'
NuGet Restore task fails (not compatible with netcoreapp2.2), but it works in Visual Studio
It seems that the version of nuget used on the Azure pipeline is not the latest version, which may cause the incompatibility issues.
To resolve this issue, you can try to add a NuGet Tool Installer task point it to a Version of NuGet.exe to install, which you simply specify the version number of the desired NuGet.exe you want to execute in the build.
Once this have been properly configured, the builds all succeeded using the latest incarnation of .net core.
Besides, if above not resolve your question, you can try to use the dotnet restore task instead of nuget restore task.
Hope this helps.
Trying to use azure yml for build pipleline to publish symbols to allow nuget pkg to be debuggable usin azure devops. I see PDB files are donwloaded to the symbols cache folder but stepping thru is asking for source file location in visual studio, even when i have indexed the source code during publish symbol.
I have tried to enable different options in visual studio debugging but nothing seems to help
Here is my yml
# 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
name: $(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r) # need this for byBuildNumber verisonScheme nuget pack
# the build will trigger on any changes to the master branch
trigger:
- master
# the build will run on a Microsoft hosted agent, using the lastest Windows VM Image
pool:
vmImage: 'windows-latest'
# these variables are available throughout the build file
# just the build configuration is defined, in this case we are building Release packages
variables:
buildConfiguration: 'Release'
#The build has 3 seperate tasks run under 1 step
steps:
# The first task is the dotnet command build, pointing to our csproj file
- task: DotNetCoreCLI#2
displayName: 'dotnet build'
inputs:
command: 'build'
arguments: '--configuration $(buildConfiguration)'
projects: 'src/Common.Core/Common.Core.csproj'
- task: PublishSymbols#2
inputs:
symbolsFolder: '$(Build.SourcesDirectory)'
searchPattern: '**/bin/**/*.pdb'
indexSources: true
publishSymbols: true
symbolServerType: 'teamServices'
treatNotIndexedAsWarning: true
symbolsProduct: '$(Build.DefinitionName)'
symbolsVersion: '$(Build.BuildNumber)'
symbolsArtifactName: '$(name).Symbols_$(BuildConfiguration)'
# The second task is dotnet pack command again pointing to the csproj file
# The nobuild means the project will not be compiled before running pack, because its already built in above step
- task: DotNetCoreCLI#2
displayName: "dotnet pack"
inputs:
command: 'pack'
arguments: '--configuration $(buildConfiguration)'
packagesToPack: 'src/Common.Core/Common.Core.csproj'
nobuild: true
includeSymbols: true
versioningScheme: 'byBuildNumber'
# The last task is a nuget command, nuget push
# This will push any .nupkg files to the 'Nuget' artifact feed
# allowPackageConflicts allows us to build the same version and not throw an error when trying to push
# instead it just ingores the latest package unless the version changes
- task: NuGetCommand#2
displayName: 'nuget push'
inputs:
command: 'push'
feedsToUse: 'select'
packagesToPush: '$(Build.ArtifactStagingDirectory)/**/*.nupkg;!$(Build.ArtifactStagingDirectory)/**/*.symbols.nupkg'
nuGetFeedType: 'internal'
publishVstsFeed: 'myNuget'
allowPackageConflicts: true
I would expect that when i am debugging nuget packages with symbols enabled with idnexed soruce code, it automatically downloads the pdf file and the source code.
Visual Studio Settings for debugger
I see PDB files are donwloaded to the symbols cache folder but
stepping thru is asking for source file location in visual studio,
even when i have indexed the source code during publish symbol.
You should let the debugger know where to find your source files. First, please rename your xx.nupkg to xx.zip and check if it contains necessary source files.
After that you can right-click Solution in Solution Explorer=>Properties=>Debug Source Files,click the New Line option to add the path of your nuget source files to the debug source files setting.
I would expect that when i am debugging nuget packages with symbols
enabled with idnexed soruce code, it automatically downloads the pdf
file and the source code.
Maybe you can get some help from this issue. You can try setting the build action of the source files as C# compiler when you create the nuget package for .net core.
I have VSTS Build which will generate the .msi file using .vdproj but I am not getting the .msi file out of the build.
I am getting the Warning MSB4078: The project file "abcdSetup\abcdSetup.vdproj" is not supported by MSBuild and cannot be built.
I am using Visual studio build task and MS build task to generate the .msi.
I have tried some ways and I installed third part task called create .msi file from VS installer Project.
I have attached the Snapshot of all the tasks using to generate this .msifile.
Please have a look and help me on this and also do let us know is there any task available in VSTS to create .msi file.
It wasn't possible until agent image Windows2019 was published. The new image is equipped with an extension for vdproj that is called Microsoft Visual Studio Installer Projects.
Steps:
Add a Command line task
Add there following line: "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\devenv.com" MyProjectDir\MySolution.sln /Rebuild Release
Remark: please note to use devenv.com (not devenv.exe). The "com" version outputs build log and errors to the console (standard output).
In 2022 today, looks like the Azure DevOps includes the Microsoft Visual Studio Installer Projects extension.
I was able to get a build using below pipeline configuration:
trigger:
- master
pool:
vmImage: 'windows-latest'
variables:
BuildConfiguration: 'Release'
BuildPlatform: 'Any CPU'
InstallerProject: 'YourInstallerProject/YourInstallerProject.vdproj'
Solution: 'YourSolution.sln'
VisualStudioPath: 'C:\Program Files\Microsoft Visual Studio\2022\Enterprise'
steps:
- task: NuGetToolInstaller#1
displayName: 'Install Nuget CLI'
- task: NuGetCommand#2
displayName: 'Restore packages'
inputs:
restoreSolution: '$(Solution)'
- task: CmdLine#2
displayName: 'Prepare for MSI build'
inputs:
script: 'DisableOutOfProcBuild.exe'
workingDirectory: '$(VisualStudioPath)\Common7\IDE\CommonExtensions\Microsoft\VSI\DisableOutOfProcBuild'
- task: VSBuild#1
displayName: 'Build primary project'
inputs:
solution: '$(Solution)'
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
- task: CmdLine#2
displayName: 'Build installer project'
inputs:
script: '"$(VisualStudioPath)\Common7\IDE\devenv.com" "$(Solution)" /Project "$(InstallerProject)" /Build "$(BuildConfiguration)|$(BuildPlatform)"'
- task: CopyFiles#2
displayName: 'Copy MSI files'
inputs:
sourceFolder: '$(Build.SourcesDirectory)'
contents: '**/$(BuildConfiguration)/**/?(*.msi)'
targetFolder: '$(Build.ArtifactStagingDirectory)'
- task: PublishBuildArtifacts#1
displayName: 'Publish artifacts'
inputs:
pathToPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: drop
Make sure to update the values of Solution and InstallerProject variables. If you would like to build with a Visual Studio version other than 2022, you must also edit VisualStudioPath variable.
I am getting the Warning MSB4078: The project file "abcdSetup\abcdSetup.vdproj" is not supported by MSBuild and cannot be built
That because MSBuild/Visual Studio does not have support for setup projects. To integrate with Azure DevOps, you will have to use devenv.
Note: starting VS 2013, .vdproj support is provided by an add-in.
That the reason why you got the error Warning MSB4078: The project file "abcdSetup\abcdSetup.vdproj" is not supported by MSBuild and cannot be built
Is there any way that we can generate .msi without setting up the
Private agent in VSTS ? Please let me know is there any task available.
I am afraid there is no such way you can generate .msi without setting up the Private agent in Azure DevOps, otherwise, we will always get the error:
Some errors occurred during migration. For more information, see the migration report: C:\VSTS-vs2017-agent\_work\9\s\Setup1\UpgradeLog.htm
I test it on the Private agent and local PC without installing the Visual Studio Installer Projects extension and got the same result. Then I installed that extension on the local PC and it works fine. So, we have to install the Visual Studio Installer Projects extension, if we want to build the setup projects.
Hope this helps.