We’ve been using TeamCity for a long time due to its widespread use in the .NET community—generally, if it can be done, someone’s already done it and blogged it. As part of new work we’re doing, we wanted to get started building and testing our work as early as possible. We ended up setting up the following steps:
KoreBuild package that the ASP.NET team has created to help in
bootstrapping projects. We set up TeamCity to execute the following Powershell
%teamcity.tool.NuGet.CommandLine.DEFAULT.nupkg%\tools\nuget.exe install KoreBuild -ExcludeVersion -o packages -nocache -pre -Source https://www.myget.org/F/aspnetvnext/api/v2 & packages\KoreBuild\build\kvm upgrade -runtime CLR -x86 & packages\KoreBuild\build\kvm install default -runtime CoreCLR -x86 & packages\KoreBuild\build\kvm use default -runtime CLR -x86 & %env.TEAMCITY_CAPTURE_ENV%
This gets the
KoreBuild package installed in
.\packages\, uses its base
tools to ensure sure the runtime and compilers are installed and ready, and most
importantly makes sure we capture the environment.
is an executable provided by TeamCity on each agent that makes sure the
environment is preserved between build steps (including
environment variables, etc.). I’m not sure where I found this info (probably
buried in the TeamCity documentation), but it was totally invaluable.
Restore NuGet packages! We restore in two phases, the first phase runs
restore to restore the packages for ASP.NET 5 projects, and the second phase
restores the .sln file to pick up the old-style .csproj that contains our data
layer (see my previous post on the subject) using TeamCity’s
To build the solution, we execute MSBuild directly on the .sln file. As TeamCity
has no support for VS2015/MSBuild 14 yet, we have to just run the executable at
%env.ProgramFiles(x86)%\MSBuild\14.0\Bin\MSBuild.exe. This does mean the
reported build output doesn’t get interpreted by TeamCity, but I can live with
that for now.
Tests! We use xUnit (its development seems to be moving much faster than NUnit,
and it’s known to work with ASP.NET 5, as it’s what the team uses for their
development), and running tests is fairly simple – the only trick is getting
output in such a way that TeamCity recognizes test runs and reports on them
correctly. The packages you need installed are
xunit.runner.aspnet, at versions
2.0.0-* for both at press time
test command is defined simply as
"xunit.runner.aspnet", and the magic incantation for TeamCity’s “Command Line”
build step is
k test -teamcity, which
uses TeamCity’s built-in service reporting to provide test output. You’ll
need to add the xUnit MyGet feed to your
NuGet.config to get the packages,
it’s at https://www.myget.org/F/xunit/.
All together, these scripts give us a robust build that ensures our tests get run. We’re still looking for a way to make coverage work (if anyone’s managed to make dotCover or NCover work with ASP.NET 5, give me a shout on Twitter), but for now, something is better than nothing.