The project: A .NET standalone application consisting in:

  • The main application that is a Windows Service containing a web server used for the web interface. Project is 90% .NET (Framework, Standard and Core) plus a few C++ libraries
  • Windows Agents that will be deployed naturally on Windows machines
  • ASP.NET Core Agents that will be deployed on Linux machines
  • WIX used for packing and creating the installer

We don't have a dedicated and experienced Devops team member, but we currently have in place a sort of CI/CD pipeline in VSTS. Nothing fancy, just a bunch of build definitions that run the unit tests for every commit and nightly the integration and Selenium tests split into several builds across multiple VMs (due to MSTest parallelization at the assembly level in order to decrease the run time), and another one that is manually started to create the installer.

In the near future we may need to switch to Jenkins and after spending some time messing with builds in it I grew really fond of the Pipeline plugin (especially with the Blue Ocean one). On the other side, I discovered that if you're not developing in the Java world, you're kind of screwed with even the most basic tools required for .NET like MSBuild and MSTest or VSTest lacking Pipeline support.

Only to be able to run the tests and display the results we had to do a bunch of steps, mostly consisting in batch scripts and add extra tools to be able to build, perform dotnet restore, nuget restore, run the tests, transform the .trx file into JUnit supported ones to be able to display them.

Considering all the info above, I humbly ask the following:

  1. What should an "upgrade" of the existing build system look like?
  2. Are there any buried resources/guides/starting points in how we could make use easier of the Pipeline in the .NET world?
  3. Anything else that I may be missing?

1 Answer 1


Specifically in answer to your 3rd question, if you are willing to look outside of the Jenkins Ecosystem there are alternatives out there that might be of value to you.

For my clients who use the Microsoft Stack and have fewer than four teams, I have been recommending the use of AppVeyor it is highly tuned for the .NET Stack and integrated very naturally with msbuild and Wix.


There are two ways of configuring AppVeyor, either through the web-based user interface or via the appveyor.yml file checked into the root of the git repository. I would strongly recommend the latter, you are welcome to start from this template:

version: 3.0.{build}

  parallel: true
  project: EVEMon.sln

  - packages -> **\packages.config

  - nuget restore

The major drawback of AppVeyor and it's cousins TravisCI and CircleCI is they don't play particularly nicely with on-premise source code management solutions, you do really need to be using GitHub or BitBucket.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.