I am trying to get a simple SpecFlow+ example up and running on Azure DevOps.
Currently I get the following Error Message:
SpecFlow+LivingDoc: An error happened during the execution: The SDK
'Microsoft.NET.Sdk' specified could not be found.
How do I install the required "Microsoft .NET Test SDK 15"?
Can somebody point me to a simple example SpecFlow setup for Azure DevOps?
All details can be found on this public Azure DevOps project:
https://dev.azure.com/FlorianBoehmak/_git/SpecFlowCalculator
EDIT
Thanks #Levi Lu-MSFT for pointing me into the right direction. I put everything together into a github repository (including a devops generator). Enjoy :-)
https://github.com/fnbk/SpecFlowCalculator
In the yaml pipeline definition, it seems that the vstest task didnot specify the test .dll file. You can try specifying the test dlls like below.
- task: VSTest#2
inputs:
testAssemblyVer2: |
**\Calculator.Spec.dll
!**\obj\**
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
And if your project is a .net core project, the Project file path field in the SpecFlow+
is the path containing your project, not the project itself. You can try setting the projectfilepath to you root directory of your source repo like below.check here
- task: SpecFlowPlus#0
inputs:
projectFilePath: '$(System.DefaultWorkingDirectory)'
projectLanguage: 'en'
Hope above can be of some help!
Related
Our build pipeline includes a YML template that is used to build all of our WCF services and Web applications. For all of the WCF services but one, it works like a charm. For this one WCF service, however, the following output is generated in the build logs during the Publish Artifact stage:
##[warning]Directory 'D:\azagent\A2_work\1381\a' is empty. Nothing will be added to build artifact 'drop'.
Our Build stage invokes a separate YML file which includes the following to build and publish the project:
- task: VSBuild#1
displayName: "Build ${{ parameters.solution}}"
inputs:
solution: ${{ parameters.solution }}
msbuildArgs: >
/p:DeployOnBuild=true
/p:WebPublishMethod=Package
/p:PackageAsSingleFile=true
/p:SkipInvalidConfigurations=true
/p:IgnoreDeployManagedRuntimeVersion=true
/p:PackageLocation="$(build.ArtifactStagingDirectory)"
platform: ${{ parameters.buildPlatform }}
configuration: ${{ parameters.buildConfiguration }}
- task: PublishBuildArtifacts#1
displayName: "Publish Build Artifact"
inputs:
PathtoPublish: "$(Build.ArtifactStagingDirectory)"
ArtifactName: "drop"
publishLocation: "Container"
As stated earlier, this works perfectly for all other WCF projects, and generates a build artifact. However, for the problematic WCF Service, no build artifact is generated. What we've observed is that no ZIP file is created in the D:\azagent\A2_work\1381\a folder (theoretically, Build.ArtifactStagingDirectory).
I have tried numerous recommended solutions to resolve this issue, all to no effect.
Adding a CopyFiles#2 task between the VSBuild#1 task and the PublishBuildArtifacts#1 task did place the files in the Build.ArtifactStagingDirectory, but they were not in a ZIP file. Further, the deployment task (later in the pipeline) failed because no ZIP file was present in the drop folder.
Adding /p:OutDir=$(Build.ArtfactStagingDirectory) did seem to produce some sort of artifact, but the deployment task still failed, claiming it could not find the ZIP file in the drop folder.
I created a test repo that contained only the WCF project (as it's normally contained in a solution containing it and a Web application) and ran the pipeline against that repo. No build artifact was created.
Ultimately, nothing I do seems to be able to get this project to generate a build artifact.
What am I missing here? What further information can I provide that will help you to help me resolve this issue?
According to Microsoft's Developer Community, this has been a known issue since August of 2019. WCF services built using a YAML pipeline do not produce build artifacts. Consequently, they cannot be deployed via YAML pipelines.
As of this date, there is neither a fix nor a workaround available from Microsoft.
We are having a problem with Azure DevOps Build Pipelines producing different files than Visual Studio locally. Our Visual Studio 2019 solution has 24 C# based projects.
Some crucial DLLs (sites don’t work without them) that are being put into Bin folder when building the solution locally in Visual Studio are missing in when building the solution via Azure DevOps Build Pipelines. The missing DLLs do exist in packages.config.
Here is a screenshot of WinMerge showing that some files exist in Azure DevOps Build Pipelines and missing in Visual Studio locally and vice versa.
[
Azure DevOps YAML build task:
- task: VSBuild#1
inputs:
solution: 'Solution.sln'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
msbuildArgs: '/p:OutputPath="$(build.binariesDirectory)\Output\bin"'
How do we debug such behavior and make our builds exactly the same locally and in Azure DevOps?
I tested with default msbuildArgs in my .Net Core Web Application, and everything works fine.
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
I don't know why, but running MSBuild without any arguments fixed the problem. If somebody could shine some light on that behavior, that would be great!
I'm trying to publish my application using a VS publish profile. When I publish through Visual Studio it works successfully, but through DevOps the publish does not work. The build is successful in both. Here is my VSBuild task definition:
inputs:
solution: '$(solution)'
msbuildArgs: '/t:Restore /p:DeployOnBuild=true /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:PublishBaseUrl=$(build.artifactstagingdirectory)'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
Try to use /p:publishUrl instead of /p:PublishBaseUrl. If it still doesn't work, share your pubxml file and DevOps build log.
You are using publish profile, so you could specify the MSBuild argument like this: /p:DeployOnBuild=true /p:PublishProfile=myprofile
Related thread: Using msbuild to execute a File System Publish Profile
My team has many test projects containing NUnit tests (version 3). We do not use the Visual Studio test runner and we do not have the test adapter (NUnit3TestAdapter) referenced in any of our projects. How can we run our tests in an Azure Devops build pipeline without going through all projects to add the test adapter reference?
We solved the problem by adding the following task to our pipeline, before the VSTest task:
- task: CmdLine#2
inputs:
script: 'nuget install NUnit3TestAdapter'
You can add nuget package to yor projects, but you don't have to go project by project. You can add it in single step.
Please take a look here:
NuGet for solutions with multiple projects
I try for several days now to publish my ClickOnce application with Azure DevOps Pipeline. Before going in detail here is what I would like to do from my release view:
I started with one artifact and 2 release stage modifying the config.deploy file with staging variables during my Staging stage and modifying the config.deploy file with production variables during my Production stage. Deployment was working fine but installation of application was not working because of hash check system.
So I decided to create 2 builds with 2 artifacts. I renamed the classic drop by a drop_staging during my first build and drop_production for my second build. I was hoping the build system (MSBuild) was able to select the correct app.Debug.config then app.Release.config file during the build and publish process.
Here is my build definition
Here is my build arguments
/target:publish
/p:ApplicationVersion=$(Build.BuildNumber)
/p:PublishURL=http://app-staging.example.com/
/p:UpdateEnabled=true
/p:UpdateMode=Foreground
/p:ProductName="App Staging"
/p:OutputPath="$(build.ArtifactStagingDirectory)\Publish\\"
Configuration is set to Staging for first build then on Production for second build. I have, of course, a Staging and Production build definition in visual Studio. I have an app.config with app.Staging.config and app.Production.config in my project.
I cannot simply add a task to transform my config file after the build because I will not respect the hash. I should find a way to say to my build to use the correct XML transformation config file. I don't see any other solution or maybe applying this transformation before the build? Is it possible? What are your solutions?
finally I could solve this by adding a file transform before my build.
In case you need more help here is my YAML detail for transformation
steps:
- task: FileTransform#1
displayName: 'File Transform: '
inputs:
folderPath: App.Example
enableXmlTransform: true
xmlTransformationRules: '-transform **\*.Staging.config -xml **\*.config'
fileType: xml
#Your build pipeline references the ‘BuildPlatform’ variable, which you’ve selected to be settable at queue time. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab, and then select the option to make it settable at queue time. See https://go.microsoft.com/fwlink/?linkid=865971
steps:
- task: VSBuild#1
displayName: 'Build solution'
inputs:
solution: Example.sln
msbuildArgs: '/target:publish /p:ApplicationVersion=$(Build.BuildNumber) /p:PublishURL=http://staging.example.com/ /p:UpdateEnabled=true /p:UpdateMode=Foreground /p:ProductName="App Staging" /p:OutputPath="$(build.ArtifactStagingDirectory)\Publish\\"'
platform: '$(BuildPlatform)'
configuration: Staging
To add to the build solution stage, you can use your visual studio Publish profile as shown below on the msbuildArgs. Please note this doesn't do the version incrementation for you
- task: VSBuild#1
displayName: 'Publish Project'
inputs:
solution: '$(projectSolution)'
msbuildArgs: '/target:publish /p:ApplicationRevision=$(applicationRevision) /p:PublishProfile="Application/PublishProfiles/HerbalPublishProfile.pubxml" /p:PublishDir="$(build.ArtifactStagingDirectory)\Publish\\"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
msbuildArchitecture: x64