Creating an ecosystem with Continuous Integration, Installer and Deployments for a WPF / UWP application

I’ve been developing Windows desktop applications for many years now, and the operations behind the development process always fascinated me. I mean matters like issues tracking, build machine, installer and deployments. Everything  that involves in a developing a successful project, that’s not directly writing code.

In recent years buzz words like Continuous Integration (CI) and Devops popped up into consciousness, which partly describe this process.

I’m going to write here about the tools and technology stacks we have to choose and implement to create a successful ecosystem for your project.

The Goal

In between buzz words, it’s a bit hard to understand what is continuous integration and what exactly we are trying to achieve.

One way of defining it is that continuous integration means to have an automated work flow, in which every time a developer checks in code, it will compile and build on a dedicated server. This dedicated server will also run tests and if the build fails, or if at least one of the tests fail, the check-in will be rejected.

Now let’s go a bit further and think about Deployment. By that, I mean the way you deliver your software to the customer. Let’s assume for now, you want to give him a setup.exe, which he can run on his PC and install the program.

Our dedicated CI server should  also produce such a setup.exe file and even upload this file to some other server dedicated to published versions that the customer can download and install.

Our CI server is also there for the QA department, which needs to get product versions, test them, open bugs and get new versions with fixed bugs.

Part of this process which I described is called Continuous Integration. But, I also want to talk about the Deployment part which is a close cousin of the continuous integration and they both compose the ecosystem of the development process.

Is this all really necessary?

Of course it is! Just consider the alternative. You’ll have developers checking in code that doesn’t compile. There will be no way to control keeping all the tests in the green. Providing a version to the QA will be a matter of zipping your Release folder, which will cause an endless amount of mistakes.

Setting up Continuous Integration

To set up the magnificent CI process I described above, you’ll need to use multiple tools. I split these tools into several categories:

  • Source Control repository
  • Build management server (aka continuous integration server)
  • Installer (Packaging tool)
  • Deployment and Updates technology
  • Unit Test framework

In each tool category, you can choose between several competing products. Let’s go through each of those, see why we need it and what options we have.

Version Control system (AKA Source Control)

There are a lot of choices for version control systems. I believe the most popular version control systems are Git, SVN, TFVC (previously known as TFS. Now TFS supports both Git and TFVC) and Mercurial.

I’d say Git is usually the best choice here, as it’s becoming the industry standard. Personally, I recently moved from TFS to Git and never been happier. Since Git is so popular, it has the most documentation and the most tooling. More importantly, the biggest source control repository providers support Git.

Source Control Repository

There’s the question of where to host your code – the repository server. We have some good choices here, especially if you’re working with Git.

  • Visual Studio Team Services is Microsoft’s cloud based code repository that integrate with Git and TFVC. There’s a free plan for a limited number of users.
  • Team Foundation Server is Microsoft’s code repository solution since 2005. The difference from VSTS is that TFS is set on premise, not on the cloud.

If choosing between TFS and VSTS, choose VSTS, unless you have to have an on premise solution for security reasons. VSTS is cheaper and easier to setup. Since VSTS is on the cloud, you get upgrades automatically as they come, whereas upgrading TFS is a complicated endeavor.

  • GitHub is a very popular git based repository with a free public repository plan (For open source projects) and paid private repository plans.
  • GitLab is another popular git based repository with better plans for enterprise on first glance.

GitHub and GitLab both offer cloud and on premise solutions (GitHub Enterprise).

All mentioned solution are a suite of products around the source code repository. They provide continuous integration, issue tracking, automated testing, code reviews, etc. We absolutely need all of these mentioned features, but we don’t have to use our source control’s products. For example, I can use VSTS as my source control, Trello for issue tracking and TeamCity as my build machine. This all means more decisions, which brings us to the next section.

Build management and Continuous Integration

As mentioned, Continuous Integration is the process which automatically tests and builds code.

For example, an automated build usually starts with the developer checking in code. Then, the CI tool observes there was a change and starts a “build” process. This will pull your latest commit, run MSBuild on the source code and if the code compiles, might run an Installer if you choose so (creating a setup.exe type of file).

We got a variety of options here:

  • TFS has very powerful continuous integration tooling. It integrates with TFS issue tracking and source control. It’s also a heavy product with lots of overhead. Since it’s installed on premise, updating to a newer TFS version can freeze development for a few days. Not recommended for small projects.
  • Visual Studio Online is Microsoft’s latest CI solution. Very similar to TFS, but on the cloud and not on premise. It’s a great improvement from TFS in ease of use. If you have VSTS as source code repository, it’s a great solution.

Both TFS and VSTS provide issue tracking, which integrates with the source control and the build machine. I worked with it and can testify it’s very convenient. It’s a great solution for enterprise, but you’ll probably have to hire at least one dedicate DevOps engineer to manage and configure everything.

  • TeamCity from JetBrains is an awesome CI tool. It’s commercial but has a free plan as well. Best thing about TeamCity is ease of use and documentation.
  • Jenkins is a Java based open source CI service. It’s completely free. Jenkins is probably the most popular CI tool out there. It may not be as easy to set up as TeamCity or VSTS though.

There are other great CI tools and I found this extensive blog post for comparison.

Installer (Packaging tool)

Installer, or a packaging tool, will transform your application into a setup.exe type of file, which can be downloaded by the user. This will usually open a wizard that eventually installs the application on the user’s computer.

This is different from a deployment tool, which distributes said setup.exe to some server and allows the user to download it. Having said that, often a single tool, like ClickOnce does both of those things.

For a UWP application distributed on Windows Store, an installer isn’t required. Publishing to the store takes care of of both packaging and distribution.

So here are some popular installer options:

  • InstallShield claim to be the industry standard installer for Windows applications. Well, it sort of is. It’s very feature rich and always up to date with the latest technologies. It can create MSI, EXE and now UWP app packages installers. You can work with a development studio to choose all the tasks the installer should do. Also, InstallShield has its own scripting language called InstallScript to write custom job. It’s pretty pricy,starting with about 700$ for the most basic plan.
  • Inno Setup is a popular free installer. I used it and was very happy with it. You basically create a text file (.iss) which contains your installer’s settings and scripts. Settings contain information like the location of your development Release folderScripts are written in Pascal language. It has good documentation and a good sized community, It produces only EXE files though, not MSI. On an update, InnoSetup will uninstall the previous version and install the new one.
  • Wix is another popular free installer. It has a steeper learning curve than InstallShield and Inno Seup, but it can produce MSI files which can be a big advantage.

Deployment & Updates

  • One way to go is Windows Store. It completely takes care of publishing and updates for you. A very convenient option if it suits your business needs and you’re willing to live with the limitations (Windows 8.x+ only, sandbox environment, etc.).
    Until recently, only UWP Apps were allowed to be published in the Windows Store. However Microsoft released the Desktop App Converter, which can wrap a WPF application into a UWP application and publish to the Store.
  • ClickOnce is Microsoft’s solution to deploying your WPF app (but not UWP). There are some mixed feelings about ClickOnce in the community and I can’t comment since I didn’t work with it myself. ClickOnce will package your application (So you might not need an Installer) and publish it to a network location. The customer can install and get updates from that network location. Or even run the application without installing locally (Everything will be cached locally). We automatically get functionality that checks for updates on each run and asks the user with a popup if he/she wants to update.
  • Chocolatey is an interesting solution to distribute your app and easily publish updates. It requires the user to install Chocolatey on his PC and then use the command line to install and update your app. Doesn’t sound user friendly but on further investigation it actually seems pretty awesome. More suited for developer customers I guess.
  • The custom solution: Publish the latest stable version of the application on your website and let users download it. This will require an installer (as described in previous section) and update support needs to be implemented. One easy way to implement updates is to poll the website on each run, checking for newer versions. Of course, you will need to handle security issues like certificate verification, manifest file verification, hashing your package to ensure it really came from you and so on.
    You probably seen it a million time in almost any software you’ve downloaded. A lot of trouble, but a valid solution, especially for consumer apps.

Unit Test framework

We have a lot of good choices with .Net unit test frameworks.

  • MSTest is Microsoft’s unit test framework, integrated right into Visual Studio. I worked with it and it’s a decent framework. It gets the job done. Best part about MSTest is that it’s integrated into VS and the entire team can use it out of the box. Another advantage is that TFS and VSTS have very good integration with MSTest. So you can easily add tests to the Gated check-in. Which means the check-in passes only if all tests pass. You can do that with all other frameworks as well, using the command line, but it’s more effort.
  • NUnit is a very popular open source unit test framework. It has many advantages over MSTest, one of which is that NUnit’s faster. You will need external tools to run NUnit and debug your tests, like ReSharper.
  • XUnit is another free open source unit test framework. It’s not as knowns as NUnit but gaining popularity.

I suggest not to overthink this decision. All the frameworks are good, and it’s just important that you have one and that everybody’s on board with it. I highly recommend running the unit tests as part of the continuous integration process. So, if a Commit (Check-in) breaks a test, it will make the build fail.


It’s amazing the amount of work involved in everything around the development. Besides writing code, we have to test it, deploy it, manage bugs and a whole bunch of other stuff.

In recent years, all these processes were given a name: Continuous Integration, Continuous Delivery, DevOps, etc. With those names, new tools arose along conferences, consulting companies and an entire industry really.

With all the burst of information, it’s hard to understand what this all really is. It also can be hard to realize it’s not rocket science and you probably don’t need to hire a consultant company which claims to multiply your productivity.

I hope in this article I was able to break down what kind of automation a desktop application company requires, and what choices you have. My goal was to paint a more complete picture on how a WPF product is developed in aspects that aren’t just writing code.

Don’t forget to share the article and happy coding!


Enjoy the blog? I would love you to subscribe! Performance Optimizations in C#: 10 Best Practices (exclusive article)

Want to become an expert problem solver? Check out a chapter from my book Practical Debugging for .NET Developers

4 thoughts on “Creating an ecosystem with Continuous Integration, Installer and Deployments for a WPF / UWP application”

  1. leszekpietrzakfluentmoney

    Thank for brief intro.
    Side note: UWP do NOT need to be published to Store.

Comments are closed.