The art of simplicity

After migrating to Azure DevOps Server 2019, I got stuck when trying to reconfigure a XAML build controller. Instead of replacing an existing build controller I got an error explaining that the build controller I was using had still a build in progress. Time to dig into the Azure DevOps database to found out what build I should cancel… The ‘go to’ table is tbl_BuildQueue. Every build in the queue has a status. Here are all the statuses for tbl_BuildQueue 0 – None 1 – In progress 2 – Queued 4- Postponed 8 – Completed 16 – Cancelled Create an update query that set all ‘In progress’ builds to Canceled: UPDATE tbl_BuildQueue SET [Status]=16 where [Status]=1 If this doesn’t help you can also check the tbl_Build table. Here are all the statuses for tbl_Build: 1 – In progress 2 – Succeeded 4- Partially Succeeded 8 – Failed 16 – Stopped Let’s update the builds here as well: UPDATE tbl_Build SET [BuildStatus]=16 where [...

After renaming our collection, we started to get build errors on our build server for the builds that were using TFS Version control. The error we got was the following: The path ‘c:\build\appname\sources ’is already mapped to workspace ‘BuildServer_123’. When I looked at the details of the workspace mapping using tf workspaces /owner:* I noticed that it was still referring to the old collection instead of the new name. That explained why TFS tried to create the workspace again, resulting in the error message above. To fix the issue I had to clear the local TFS cache on the build server. This can be done by deleting the content of the following folder: C:\Users\{BuildServiceAccount}\AppData\Local\Microsoft\Team Foundation\{VersionNumber}\Cache {BuildServiceAccount} refers to the account that is used to run the build agent and {VersionNumber} refers to the used Azure DevOps version.

Last week a colleague asked me to explain the concept of Pull Requests using our Azure DevOps Server instance. I followed the steps as described here to active a branch policy on their master branch. Then I did a local change, committed it and tried to push it to the master branch, but instead of getting an error stating that I couldn’t push to this branch, it succeeded! I tried it a few times and every time I was able to push no matter what policies I activated. Was it a bug? Or did I do something wrong? Turned out it was neither. Let’s find out what happened: Go to the Code –> Branches section inside Azure DevOps(TFS). Click on the 3 dots … and choose Branch Security. On the Security screen, I clicked on my user account and had a look at the permissions on the right. I had the Exempt from policy enforcement permission enabled. This overrules are policies and explained why I was able to push my changes. Some extra notes from the documentati...

I thought that the first week of the new year would be a good time do some cleaning and decided to remove some old branches from Team Foundation Server Version Control. However deleting one of the branches failed with the following error message: Another user had one of the files locked inside his (private) workspace which prevented me from deleting this branch. As I couldn’t contact this person, I had to find another solution. Remove the lock Removing a lock can be done using the tf undo command: Open a Visual Studio command prompt Enter the following command tf undo /workspace:FRIEND-PC;personname  /collection:http://servername/DefaultCollection $/xxxx/ProjectFolder/ProjectName/filepath/filename.css Here is an example: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise>tf undo /workspace:"Framework en Tooling 169;Bart Wullems" /collection:http://tfs.server.be:8080/tfs/defaultcollection "$/Framework en Tooling/Ma...

Got a call for help from a colleague who couldn’t get an Acceptance release out of the door. Problem was that the automated build responsible for packaging and deploying the Acceptance version failed. He asked me to take a look… Inside the build logs we noticed the following error message: 2018-11-13T06:35:22.4133574Z (CoreCompile target) -> 2018-11-13T06:35:22.4133574Z   CSC : error CS0006: Metadata file 'D:\b\4\agent\_work\_temp\.sonarqube\resources\1\Google.Protobuf.dll' could not be found [D:\b\4\agent\_work\40\s\MTIL.Domain\MTIL.Domain.csproj] 2018-11-13T06:35:22.4133574Z   CSC : error CS0006: Metadata file 'D:\b\4\agent\_work\_temp\.sonarqube\resources\1\SonarAnalyzer.CSharp.dll' could not be found [D:\b\4\agent\_work\40\s\MTIL.Domain\MTIL.Domain.csproj] 2018-11-13T06:35:22.4133574Z   CSC : error CS0006: Metadata file 'D:\b\4\agent\_work\_temp\.sonarqube\resources\1\SonarAnalyzer.dll' could not be found [D:\b\4\agent\_work\40\s\M...

Didn’t had my best day yesterday as I was trying to rollout Team Foundation Server 2018 at a customer. When we tried to start the installation, it failed while installing the .NET Framework 4.7 with a not-so-clear error message “Cannot find object or property”. Inside the setup log, we found a little more information: [1930:1564][2018-08-16T09:54:05]i319: Applied execute package: netfxfullredist, result: 0x80092004, restart: None [1930:1564][2018-08-16T09:54:05]e000: Error 0x80092004: Failed to execute EXE package. [1AC0:00A8][2018-08-16T09:54:05]i351: Removing cached package: netfxfullredist, from path: C:\ProgramData\Package Cache\76054141A492BA307595250BDA05AD4E0694CDC3\ [1AC0:00A8][2018-08-16T09:54:05]i372: Session end, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{2b3bf919-c7d8-41a9-bff7-734a9750b00c}, resume: None, restart: None, disable resume: No [1AC0:00A8][2018-08-16T09:54:05]i330: Removed bundle dependency provider: {2b3b...

UPDATE: This is indeed an issue confirmed by Microsoft:  https://blogs.msdn.microsoft.com/sqlreleaseservices/issue-with-security-update-for-the-remote-code-execution-vulnerability-in-sql-server-2016-sp2-cu-august-14-2018/ . Thanks Michael for sending me the link. After installing the security update below on our TFS database tier, we could no longer connect to the Work hub in TFS(other features still seemed to work). The error we got on the work page was: TF246017 Team Foundation Server Could Not Connect to the Database.Verify that the server that is hosting database is operational,and that network problem are not blocking communication with server. In the windows event logs, we found the following information: A user request from the session with SPID 61 generated a fatal exception. SQL Server is terminating this session. Contact Product Support Services with the dump produced in the log directory. I couldn’t find a (better) solution, so we decided to rollback this secu...

Microsoft created a consolidated resource site with all kinds of information related to DevOps. It not only contains learning material about DevOps practices but also about Agile Methods, Git version control. You can also see how Microsoft is applying DevOps for their own products and assess you own DevOps maturity.

On one of my projects, we noticed flaky test behavior where the test task somethings succeeded but sometimes failed to correctly initialize and run the test adapters. As the issue seemed related not to a specific test, but to the setup of the test task itself we had no clue what whas going on. By comparing the succeeded and failed cases, we noticed that when the test task failed, we had the following warning in our build log: Agent 'AgentXXX' is using a deprecated version '1.105.7'. You will not be able to use this version of agent with the next major version of Team Foundation Server. Migrate to the latest 2.x version of agent. For more information, see https://go.microsoft.com/fwlink/?linkid=851067 . This brought us to the solution. We had 2 build agents running on our build server. One agent was an older 1.x version  where the other one was using the 2.x version. Every time the build was triggered on the new agent it succeeded, where it failed on the old on...

A colleague mentioned to me he was the following warning on our build server: Agent 'AgentName' is using a deprecated version '1.105.7'. You will not be able to use this version of agent with the next major version of Team Foundation Server. Migrate to the latest 2.x version of agent. For more information, see https://go.microsoft.com/fwlink/?linkid=851067 . I was suprised to see this as I recently updated all agents . Still I’m stuck with version 1 agents… It turns out that there are 2 types of agents: Windows specific agents having number 1.x cross platform agents having number 2.x The thing is that the Update All Agents button will only upgrade to a more recent minor version but will not do an upgrade to a new major version. If you want to upgrade to a new major version of the agent, you’ll have to uninstall the old agent and install the new one yourself.

I blogged earlier about the existence of the .tfignore file in Team Foundation Server source control similar to the .gitignore file in GIT. Still they are a lot of developerd who are unaware of the existence of this file. With the .tfignore file, you can configure which kinds of files are ignored by placing it in the folder where you want rules to apply. The effects of the .tfignore file are recursive. However, you can create .tfignore files in sub-folders to override the effects of a .tfignore file in a parent folder. Here is a good sample file to get started with: To automatically generate a .tfignore file In the Pending Changes page, in the Excluded Changes section, select the Detected link. The Promote Candidate Changes dialog box appears. Select a file, open its context menu, and choose Ignore this local item , Ignore by extension , Ignore by file name , or Ignore by folder . Choose OK or Cancel to close the Promote Candidate...

After setting the Language version to C# latest minor version for my project, our TFS build started to fail with the following error message: Error CS1617: Invalid option 'latest' for /langversion; must be ISO-1, ISO-2, Default or an integer in range 1 to 6 While looking through the build logs I noticed that the build server was still using MSBuild v14 instead of 15. I first thought that my build agents were not up to date, so I triggered an upgrade: http://bartwullems.blogspot.be/2017/09/team-foundation-serverupgrade-your.html This made no difference, the used build tasks were not able to discover the newer version of MSBuild on the build server as they didn’t use VSWhere.exe yet. In the end I decided to do an upgrade of TFS(a TFS 2017 instance) to TFS 2017 Update 3. After doing that, a new version of the Build task was available that correctly found MSBuild v15.0 and allowed me to use the new C# features. Finally!

Microsoft released a Test and Feedback extension for Chrome and Firefox as a replacement for the exploratory testing feature in Microsoft Test Manager. Earlier versions of this extension were rather limited in functionality but with the most recent version you can: Take screenshots of any application on your desktop(not only inside the current browser chrome) Take screen recordings and save them as videos Getting started Go to the Visual Studio Marketplace: https://marketplace.visualstudio.com/items?itemName=ms.vss-exploratorytesting-web Click on one of the links in the Supported Browser section I’m using Chrome, so I click on Install . You will be taken to Google Chrome web store in a new tab. Follow the steps from Chrome web store to install the extension. After the installation is done, you see a new icon on the top right in your browser, next to the address bar. When you click on the icon, a popup is shown. ...

In a previous post I mentioned how to run and publish your Visual Studio Unit tests on your build server. By using the dotnet test command with the –logger:trx option, tests results were generated in a format that can be published to TFS. One problem we noticed when applying this solution was that the default naming convention sets a unique name(based on the test execution date) for every generated trx file. This sounds fine but the problem was that for every run of our build pipeline, new trx files were generated. As a consequence, when trying to import the test results using the Publish Test Results task, test result files from previous builds were imported as well, resulting in an ever increasing number of published test results. To solve this, I added an extra option to the dotnet test command and explicitly specify the filename: dotnet test --logger trx;logfilename=TEST.trx In the Publish Test Results task, I updated the wildcard to only include TEST.trx files: ...

After upgrading our unit tests to MSTest v2 we noticed that our tests were no longer discovered by the VSTest task on our build agent. As a solution, we decided to invoke the test execution ourself. Therefore I added 2 tasks to our Build definition: One command line task to execute dotnet test One task to collect and publish the test results In the command line task I configured the following settings: To execute the dotnet command we specify ‘dotnet’ as the Tool We also specify the following arguments: test: we want to execute the test commando --no-restore: the package restore already happened in a previous build step and shouldn’t be re-executed here --no-build: assembly compilation already happened in a previous build step and shouldn’t be re-executed here --logger:trx: output the test results in the trx format A last important setting that we change is the ‘Continue on error’ setting is set to true. If we don’t do t...

If you upgrade your TFS installation to a newer version, a new version of the build agent is available as well. To upgrade your agents, you have 2 options: If a new major version of the agent is released, you’ll have to manually delete the old agent and install a new agent. If a new minor version of the agent is released, the existing agent is upgraded automatically when it runs a task that requires a newer version of the agent. If you want to trigger the update manually, you can go to the Agent Pool hub, right click on a Queue and click on Update All Agents . More information at https://docs.microsoft.com/nl-nl/vsts/build-release/concepts/agents/agents#agent-version-and-upgrades

Today one of my colleagues in our ALM team asked for help. For a customer we upgraded their TFS environment to TFS 2017. One of the changes we had to do along the way was replacing the existing MultiValue control by a newer version( https://github.com/Microsoft/vsts-extension-multivalue-control ). We followed the steps as mentioned here( https://github.com/Microsoft/vsts-extension-multivalue-control/blob/master/xmldetails.md ) but the control didn’t appear. Here is the template XML that we were using(I removed some content): Although we couldn’t see any difference with the steps mentioned above, it didn’t work. When I had a look I noticed that the extension is only registered in the WebLayout part of the Form. Remark: In TFS you always had 2 layouts(a layout and a weblayout), the first one applies when opening a work item in Visual Studio or Test Manager, the weblayout applies when opening a workitem in the browser. We first tried to add the extension to the layout ...

After some time, your build agents start to eat up more and more disk space on your build server. Before I always cleaned it up manually when I get a warning from our system monitoring tools, but there is actually a better way I wasn’t aware of. It is possible to schedule a Maintenance Job to clean up the _work folder in the agent: Remark: As this has an impact on the availability of your pool it is recommended to limit the max percentage of agents running maintenance(25% by default). Where can you find these setting? Login to your TFS or VSTS portal Open the Administration Section of the portal and go to the Agent Pools section On the Agent Pools page, select a specific pool from the list of available pools On the right choose the Settings tab

Starting from Team Foundation Server 2017, the Code Search feature that was available for a while in VSTS, gets an on-premise equivalent. The feature is built on top of a customized version of ElasticSearch . However the integration between the 2 products(TFS and ElasticSearch) is rather limited right now. To help you maintain your ElasticSearch instance, Microsoft has a set of Powershell scripts available that allow you to: Pause and Restart indexing Clean and reset your ElasticSearch instance Trigger code indexing Etc… A must have for every TFS administrator…

I had a hard time yesterday finding out how I could see what Test Results are available for specific Test Cases. In case I ever need it again(or someone else is as bad in finding it’s way through the TFS interface as me), here are the steps: Open the TFS web portal and go to a specific Team Project. Go to the Test Tab Select a Test plan from the dropdown on the left and click on the Test suite that contains your test cases On the right you see the list of available test cases Click on the Show/Hide details button in the far right corner A detail pane is shown on the right Click on the ‘Test case’ text next to the Pane and change it to ‘Test results’