This story goes back till 2010 when there was no deployment tool e.g. Release Management or Octopus Deploy available at the time and we were deploying to production via XAML Build. There’s only one website that survived using this process and that’s SSW website.
SSW Website is massive. We are talking about GBs of data which is stored in VSTS. A clean deployment would probably take hours hence deploying just changes was our best shot. One of our SSW developers built a tool that checks the last successful TFS Build, the last deployed version to production, and then copies over the deltas to our production servers. This process used to work for years until our recent migration to VSTS.
Migration from TFS to VSTS
Soon after the migration we started seeing the following error message.
Not very descriptive but at least it highlighted where the problem originated – in TfsSync utiltity. In the logs I found heaps of 401 (Unauthorized) exceptions which didn’t really make sense. Our TfsSync tool config has been updated, it pointed to the right VSTS account and the it was running under a service account which we always used for our XAML Build.
I decided it’s time to move it to Team Build and ditch the XAML Build because it was too time consuming to debug.
The VSTS Agent was configured exactly the same way but the TfsSync.exe was still failing with the same error.
As a last resort I tried to run the tool manually directly from the Build server and to my surprise I’ve seen this:
Wait a minute! We haven’t seen this before…where did it come from and why?
It turns out that no matter how “old” Team Explorer DLLs you use (in our case they were v11.0) it’s the server who controls how you get authenticated. VSTS will ask you to reenter your credentials every now and then when your authentication token expires.
So if you have a code like this
…you are going to see the sign-in dialog because VSTS needs you to confirm your identity first. Once you do that everything works as expected. This also explains why the service returned 401 error straight away. Services run in a session 0 which is isolated from the interactive desktop hence they cannot show UI.
Luckily the latest Team Explorer API gives you plenty of options to silently authenticate with VSTS including:
- OAth token
- Azure Acitve Direcotry (Username & Password)
- Personal Access Token
More available in the Microsoft docs.
For us the best solution was to use the VssAadCrednetials with Username and Password because it required the least refactoring of all.
All I had to do is to pass VssAadCredentials to a TfsTeamProjectCollection constructor and that did the trick.
Note: These two SOAP solutions didn’t work as advertised and they displayed the dialog anyway. I am yet to investigate why this is so because I’d much more prefer to avoid using Username & Password even though they are encrypted in the app.config.