Over the course of this year we have been building a new vsts agent on the .NET Core platform. The new agent not only includes a number of new features but it also gives complete feature parity across all of our supported platforms and it is open source. This new agent will ship with the next version of TFS and is the default download from VSTS today for private agents. Starting today we will be rolling out the new agent to the virtual machines in the hosted pool on VSTS.
In order to drive better stability and scale we have made one change to this agent in how it works with TFVC based repositories that might impact some builds. With the previous build agent we attempted to use local workspaces instead of the more traditional server based workspaces. As it turns out this change caused a number of problems for customers with workspace conflict errors and overall slowness in very large workspaces. In order to remedy these problems, we decided to revert to the behavior of the older XAML agents and use server workspaces.
Potential issue for some builds
Unfortunately switching to server based workspaces means that your files will be read-only until they have either been checked-out for edit or marked as read-write explicitly. This means that if you have a build process that modifies files that are checked into your source tree without making a copy of them or otherwise marking them as editable then you will see errors in your build. To alleviate this issue, you simply need to explicitly mark any files that your build process needs to edit as read-write using an attrib -r <filename> before running program or script that modifies them.
If you see any other issues in your builds, please comment here or on twitter @chrisrpatterson.