TeamCity is a Continuous Integration system that will automatically build your dotnet solution when you commit your changes to source control. This will help you speed up your development, test and deployment cycles. When setting up our CI system I found that the easiest system was TeamCity but documentation was disperate and didn't always cover .NET. This series follows my progress of setting CI using teamcity for a dotnet environment.
1. Getting Started
The first post covers everything you need to do to setup CI. Step by Step screenshots lead you through the process of installing and getting teamcity working with Visual Studio Build Process. By the end of the post you will have TeamCity installation automatically compiling your solution when you commit a change to source control.
2. Moving to MsBuild
A MSBuild build proccess gives your some extra control over a standard .sln Build. The post details a minimal MSBuild file you will need to add to your sourcefolder and how to Build it. It also shows you how to Build using the .NET SDK instead of using Visual Studio.
3. Automatic Assembly Versioning
Now you are using MSBuild you can automatically set assembly Build Numbers from the Build Number in TeamCity and/or your Source Control revision. This means your Build Outputs/Artifacts will be automatically Built with incrementing version numbers. This one of the first steps towards continuous Deployment.
4. Using IIS
5. Using IIS (part 2)
CI is getting more important and you want to access if from anywhere in the world. Because TeamCity is written in Java it doesn't nativlty run on IIS and will install to a non standard Port. This post explains how you can access TeamCity via IIS if you don't have a dedicated box for your CI server and you want to access it on a web friendly URL/you are using IIS to host other sites on the same box.