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

<p>For my clients who use the Microsoft Stack and have fewer than four teams, I have been recommending the use of <a href="https://www.appveyor.com/" rel="nofollow noreferrer">AppVeyor</a> it is highly tuned for the .NET Stack and integrated very naturally with <code>msbuild</code> and Wix.</p>

<p><a href="https://i.sstatic.net/96imo.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/96imo.png" alt="AppVeyor"></a></p>

<p>There are two ways of configuring AppVeyor, either through the <a href="https://ci.appveyor.com" rel="nofollow noreferrer">web-based user interface</a> or via the <a href="https://www.appveyor.com/docs/appveyor-yml/" rel="nofollow noreferrer"><code>appveyor.yml</code> file</a> checked into the root of the git repository.  I would strongly recommend the latter, you are welcome to start from this template:</p>

<pre><code>version: 3.0.{build}

build:
  parallel: true
  project: EVEMon.sln

cache:
  - packages -&gt; **\packages.config

install:
  - nuget restore
</code></pre>

<p>The major drawback of AppVeyor and it's cousins <a href="https://travis-ci.org/" rel="nofollow noreferrer">TravisCI</a> and <a href="https://circleci.com/" rel="nofollow noreferrer">CircleCI</a> is they don't play particularly nicely with on-premise source code management solutions, you do really need to be using GitHub or BitBucket.</p>

CC BY-SA 3.0
2017-04-06T09:23:37.683Z
2017-04-06T15:56:46.897Z
2017-04-06T15:56:46.897Z
Richard Slater
<p>The project:
A .NET standalone application consisting in:</p>

<ul>
<li>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</li>
<li>Windows Agents that will be deployed naturally on Windows machines</li>
<li>ASP.NET Core Agents that will be deployed on Linux machines</li>
<li>WIX used for packing and creating the installer</li>
</ul>

<p>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. </p>

<p>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.</p>

<p>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 <code>.trx</code> file into JUnit supported ones to be able to display them.</p>

<p>Considering all the info above, I humbly ask the following:</p>

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

CC BY-SA 3.0
2017-04-05T22:34:48.490Z
side note re. `We don't have a dedicated and experienced Devops team member`: DevOps is arguably a team member role, see [What is the difference between Sysadmin and DevOps Engineer?](http://devops.stackexchange.com/questions/157/what-is-the-difference-between-sysadmin-and-devops-engineer)
Dan Cornilescu
<jenkins><jenkins-plugins><build-pipeline><dotnet>
Continuous Integraton using Jenkins Pipeline for a .NET project
Cosmin
# Continuous Integraton using Jenkins Pipeline for a .NET project

(Asked by: username_0 on 2017-04-05)

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?

**Tags:** jenkins, jenkins-plugins, build-pipeline, dotnet

> **Comments:**
> **username_1**: side note re. `We don't have a dedicated and experienced Devops team member`: DevOps is arguably a team member role, see [What is the difference between Sysadmin and DevOps Engineer?](http://devops.stackexchange.com/questions/157/what-is-the-difference-between-sysadmin-and-devops-engineer)  

---

## 1 answers

### Answer by username_2 on 2017-04-06. Score: 4

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}

build:
  parallel: true
  project: EVEMon.sln

cache:
  - packages -> **\packages.config

install:
  - 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.


---

