How to Configure TeamCity for .NET Framework Builds

| January 28, 2020 | in

Software Development Tips & Tricks

Setting up builds is not my favorite part of the day.

It always feels like a lot of time invested in something that only takes a few minutes to run, and that few minutes of work results in waiting several more minutes to get an answer. Try something, wait five minutes, get an answer. This is a slow way to work.

But builds are essential. Setting up good builds takes a burden off the developers doing pull requests and deploying to different environments.

In this post, I’m going to document the steps to configure TeamCity for builds of a .NET Framework project. While this isn’t difficult, it’s something I haven’t had to do in a while. Typically we use a lot of Azure Dev Ops for builds. But sometimes we have projects with a lot of infrastructures already running in AWS, and in these cases adding Azure Dev Ops to the mix seems like overkill.

So let’s get started.

The first step with TeamCity is to create a project.

Creating a project in TeamCity

When creating a project, TeamCity will want you to associate the project with your source change management system of choice (such as GitHub).

Creating a project from a URL in TeamCity

One awesome thing about TeamCity is it will automatically try to determine which build steps you need. In this case, I selected “Visual Studio (sln)”.

Auto-detected build steps in TeamCity

Now you should have a working build.

You can add build steps for many things. Below I have added a step for running unit tests.

You can also add the ability for TeamCity to post failed builds back to GitHub. That way, you see on the pull request screen that your build has failed.

But there is a very satisfying feeling when getting your builds working.

And that is all it takes.

So why do I prefer Azure Dev Ops for setting up and managing my builds? The tight integration with GitHub and the tight integration with Azure makes using Azure Dev Ops so smooth you forget all the little steps you must go through to get builds set up. Also, with Azure Dev Ops, it feels like you are getting a service that is easy to use. With TeamCity, it feels like you are getting a tool. A very powerful tool, but a tool you need to know how to wield.