Building .NET projects on jetbrains/teamcity-agent Docker Windows containers

Hi,

we are trying to move from "traditional" build agents hosted in VMs to using Docker. The hole product is run on Windows, thus forcing us to use Windows containers. We have done some exploratory testing using a TeamCity docker agent to obviously host an agent but also to build a .NET application. Here comes the issue. First build works fine, the second fails directly because it cannot remove a binary from the obj-folder from the previous build. If I try to remove it myself I get a prompt saying it is locked by another process, vmwp.exe more specifically. Restarting the container solves the problem but is obviously not a viable solution.

I have tried the following without success

• Removing any antivirus-program that could cause this. I have read that vmwp.exe could get this behavior with antivirus-programs.
• Tried to run the docker image in process isolation but for that I need the host to have the same OS version. This might be solved we would create a VM with the exact version as the container. For reference, I get the error "The container operating system does not match the host operating system." from the Docker daemon.

Versions used:

• TeamCity Docker agent: jetbrains/teamcity-agent:2022.04.3-windowsservercore
• TeamCity Server: TeamCity Enterprise 2022.04.3 (build 108706)
• Host OS: Microsoft Windows [Version 10.0.19044.2075]
• Docker: Docker Desktop 4.12.0 (85629) 

Alternative solution:

We have looked into using TeamCity support in certain runner to use Docker images for build steps. This might be a much better solution with some caveats:

1. Running one build step for .NET build in Docker, mcr.microsoft.com/dotnet/sdk:6.0.100-nanoserver-20H2, adds an overhead run-time of about 15 seconds. This means that a simple build that earlier took 15 seconds now takes about 30 seconds using Docker Wrapper (version 108706). That is unreasonable and I am not sure if it can be mitigated somehow.
2. We use for instance the sonnarScanner for SonarQube analysis. This requires steps before and after the build step. Only doing the build step in Docker does not work.

Questions:

• I am really not sure this is the best way to go about this. What is your recommended way of doing this? How can we move from clunky VMs to a more slim and controlled build environment?
• Do you have any idea why running a build step in docker container (mcr.microsoft.com/dotnet/sdk:6.0.100-nanoserver-20H2) is so much slower? It certainly seems unreasonable. (see Point 1 under Alternative solution)

Would be great to hear your thoughts!

Thank you,

Patrik Hillbo

Dev. Engineer