Migrate your TFS to VSTS

I’ve discussed a lot with many customers over the benefit of VSTS over TFS, especially for small companies, where there is no budget for a dedicated TFS administrator. The usual risk is not updating TFS, loosing the update train and then have a problem doing upgrades like TFS 2008 to TFS 2017.

For those realities, adopting VSTS is a huge benefit, no administration costs, no hardware costs, automatic upgrade, accessible from everywhere, same licensing (license for VSTS are also valid for TFS) and much more.  Also one of the original limitation, the inability to customize process, is now gone and, for certain aspect, VSTS is superior to the on-premise version (in VSTS you can do less customization but everything is done with Web Interface without needs to edit XML process file)

If you are a small company, VSTS is the perfect tool, it contains everything for DevOps, zero maintenance cost, extensible and free for the first 5 users.

To perform the migration Microsoft released a dedicated tool to do a complete migration, you can find details here https://www.visualstudio.com/team-services/migrate-tfs-vsts/ the process is well documented, with a dedicated step by step guide.


Figure 1: Step by step migration guide download.

Please read the guide carefully and verify the required version for TFS to being able to migrate. As you see from Figure 1 you can migrate from TFS 2017 update2, TFS 2017 Update 3 and TFS 2018 RTW. Please notice that you cannot use a migrator tool on a TFS version different from the version declared by the tool. The tool will be updated to reflect and support the new version of TFS, and it will support only the most recent versions. If you have an old TFS instance, the suggestion is to migrate as soon as possible, then plan for the migration.

If you need support, check one of the official DevOps partner at this address http://devopsms.com/SearchVSTSPartner, they can support your company for a smooth and successful migration, especially if you are a large organization and have a big TFS instance.

Gian Maria

TFS 2018 is out, time to upgrade

Some days are passed, but it is good to remind you that TFS 2018 is finally out. Some people are surprised because after TFS 2015 we had TFS 2017 and we are still in 2017 and we already have version 2018, but this is the good part of the ALM tools in Microsoft, they are really shipping tons of new goodness each year :).

Release note page contains all the details about the new version, from that link you have a small 13 minute video that explain what is new in this version and as usual in the page you have a detailed list of all the news with detailed information about each of the new features.


I strongly suggest you to start verifying system requirements and planning for the upgrade, because, as usual, it is a good habit to install the latest bit if possible, to avoid having to do a big bang upgrade after years of not upgrading.

It is always a good practice not to skip a single major version, the upgrade process will be smoother than doing a big jump (like people migrating from TFS 2008 to 2015/2017

Apart new features, the above link informs you on all the features that are actually removed from this version, because they were deprecated in the old version. This can be an update blocker, but I strongly suggest you to start thinking to a remediation pattern, instead of being stuck forever in the 2017 version.

From removed features, Team Room is probably the least impacting, very few people are using it, and you can use Slack or other tools. Tfs Extension for SharePoint were also removed, this is also a feature that very few people will miss. The Lab Center in Microsoft Test Manager was also removed, but probably the most important missing feature is the XAML Build support. In TFS 2018 you can only use the new build introduced with TFS 2015, no excuses guys, you really need to migrate every XAML build to the new format, as soon as possible.

Happy upgrading.

Gian Maria

VSTS build failed test phase, but 0 tests failed

I had a strange situation where I have a build that suddenly starts signal failing tests, but actually zero test failed.


Figure 1: No test failed, but the test phase was marked as failed

As you can see in Figure 1, the Test step is marked failed, but actually I have not a single test failed, indeed a strange situation. To troubleshoot this problem, you need to select the failing step to verify the exact output of the task.


Figure 2: The output of the Test Step action is indeed test failed

As you can see in Figure 2, the VS component that executes the tests is reporting an error during execution, this imply that, even if no test is failing, something wrong happened during the test. This happens if any test adapter write to the console error during execution and it is done to signal that something went wrong.

Failing test run if there are error in output is a best practice, because you should understand what went wrong and fix it.

To troubleshoot the error you need to scroll all the output of the task, to find exactly what happened. Looking in the output I was able to find the reason why the test failed.

2017-11-17T14:43:19.6093568Z ##[error]Error: Machine Specifications Visual Studio Test Adapter – Error while executing specifications in assembly C:\A\_work\71\s\src\Intranet\Intranet.Tests\bin\Release\Machine.TestAdapter.dll – Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

If an adapter cannot load an assembly, it will output error and the test run is marked as failed, because potentially all the tests inside that assembly were not run. This is a best practice, you do not want to have some test skipped due to load error and still have a green build.

Machine Specification test adapter tried to run test in Machine.TestAdapter.dll and this create a typeLoadException. Clearly we do not need to run test in that assembly, because TestAdapter.dll is the dll of the test adapter itself and does not contains any test. This problem indeed happens after I upgraded the nuget package of the runner, probably in the old version the TestAdapter.dll did not creates errors, but with the new version it does throw exception.

The problem lies in how the step is configured, because usually you ask to the test runner to run tests in all assemblies that contains Test in the name. The solution was to exclude that assembly from test run.


Figure 3: How to exclude a specific dll from the test run

And voilà, the build is now green again. The rule is, whenever the test step is failing but no test failed, most of the time is some test adapter that was not able to run.

Gian Maria.

Decide to publish artifacts on Server or Network Share at queue time

A build usually produces artifacts and thanks to the extreme flexibility of VSTS / TFS Build system, you have complete freedom on what to include as artifacts and where you should locate them.

Actually you have a couple of options out of the box, a network share or directly on your VSTS / TFS Server. This second option is especially interesting because you does not need a special network share and you do not have permission issue (every script or person that can access the server and have build permission can use the artifacts). Having everything (build result and artifacts) on the server simplify your architecture, but it is not always feasible.

Thanks to VSTS / TFS  you can store artifacts of builds directly in your server, simplifying the layout of your ALM infrastructure.

The main problem with artifacts stored in the server happens with VSTS, because if you have really low upload bandwidth, like me, it is really a pain to wait for my artifacts to be uploaded to VSTS and is is equally a pain to wait for my releases to download everything from the web. When your build server is local and the release machine, or whatever tool need to consume build artifacts is on the same network, using a network share is the best option, especially if you have good Gigabit network.

The option to “where to store my artifacts” is not something that I want to be embedded in my build definition, I want to be able to choose at queue time, but this is not possible, because the location of the artifacts cannot be parameterized in the build.

The best solution would be to give user the ability to decide at queue time where to store artifacts. This will allow you to schedule special build that store artifacts on a network share instead that on server

The obvious and simple solution is to use Two “Publish Artifacts” task, one configured to store artifacts on the server, the other configured to store artifacts on a network share. Then create a simple variable called PublishArtifactsOnServer and run the Publish Artifacts configure to publish on the server only when this value is true.


Figure 1:

In Figure 1 there is the standard configuration of a Publish Artifact task that stores everything on the server and it is run on the custom condition that the build is not failed and the PublishArtifactsOnServer is true. Now you should place another Publish  Artifacts task configured to store drops on a network share.


Figure 2: Another Publish Artifacts task, configured to run if PublishArtifactsOnServer is not true

In Figure 2 you can verify that the action is configured with the very same option, the only differences are the Artifact Type that is on a File Share with the corresponding network share and the Custom condition that runs this action if the build is not failing and if the PublishArtifactsOnServer variable is NOT equal to true.

This is another scenario where the Custom Conditions on task can allow you for a highly parameterized build, that allows you to specify at queue time if you want your artifacts stored on the server or onto a network share. The only drawback to this solution is that you need to duplicate your tasks, but it is a really simple things to do. Now if you queue a build where PublishArtifactsOnServer is true, you can verify that your artifats are indeed stored on server.

2017-07-07T16:28:21.0609004Z ##[section]Starting: Publish Artifact: primary drop 
2017-07-07T16:28:21.0618909Z ==============================================================================
2017-07-07T16:28:21.0618909Z Task         : Publish Build Artifacts
2017-07-07T16:28:21.0618909Z Description  : Publish Build artifacts to the server or a file share
2017-07-07T16:28:21.0618909Z Version      : 1.0.42
2017-07-07T16:28:21.0618909Z Author       : Microsoft Corporation
2017-07-07T16:28:21.0618909Z Help         : [More Information](https://go.microsoft.com/fwlink/?LinkID=708390)
2017-07-07T16:28:21.0618909Z ==============================================================================
2017-07-07T16:28:22.6377556Z ##[section]Async Command Start: Upload Artifact
2017-07-07T16:28:22.6377556Z Uploading 2 files
2017-07-07T16:28:27.7049869Z Total file: 2 ---- Processed file: 1 (50%)
2017-07-07T16:28:32.7375546Z Uploading 'Primary/xxx.7z' (14%)
2017-07-07T16:28:32.7375546Z Uploading 'Primary/xxx.7z' (28%)
2017-07-07T16:28:32.7375546Z Uploading 'Primary/xxx.7z' (42%)
2017-07-07T16:28:37.7827330Z Uploading 'Primary/xxx.7z' (57%)
2017-07-07T16:28:37.7827330Z Uploading 'Primary/xxx.7z' (71%)
2017-07-07T16:28:40.3306829Z File upload succeed.
2017-07-07T16:28:40.3306829Z Upload 'C:\vso\_work\13\a\primary' to file container: '#/534950/Primary'
2017-07-07T16:28:41.4309231Z Associated artifact 214 with build 4552
2017-07-07T16:28:41.4309231Z ##[section]Async Command End: Upload Artifact
2017-07-07T16:28:41.4309231Z ##[section]Finishing: Publish Artifact: primary drop 

As you can see from the output of the task, the task uploaded the artifacts to the server. Now you can schedule another build with PublishArtifactsOnServer to false and you should see that the other task was executed, now the artifacts are on a network share.

Gian Maria

Hyper-V and Windows AutoLogon

When you configure build agents and especially when you configure Release Agents for VSTS, it is quite normal to have some installations where you want to use AutoLogon. This is needed whenever you want to run integration tests that needs to interact with the UI. Having autologon enabled avoid the need to manually login and start the agent when the machine is rebooted, because you always have a user session opened that runs the agent.

There are lots of articles, like this one that explain how to configure everything, but last Saturday I had a problem, because I had a Windows Server 2016 where that technique does not work. I rebooted the machine, but the hyper-v console shows me the login pane and I was really puzzled.


Figure 1: Login screen in Hyper-V console.

As you can see from Figure 1, the Hyper-V console shows the login page, so I incorrectly believed that the autologon did not work. I said incorrectly because trying to troubleshoot the problem, a friend told me to check the Hyper-V manager console, and here is what I see


Figure 2: Small Thumbnail of the VM in Hyper-V snap-in.

From Figure 2 you can see that the Thumbnail of the VM does not show the login page, but it shows a user session logged into the machine. A quick check confirmed me that the agent was online, so the Automatic Logon worked, but my Virtual Machine console still shows me the logon screen.

The reason is in the Enhanced session feature, available in the View menu of the Virtual Machine console. The Enhanced session is used to allow windows resizing, clipboard transfer and so on and uses Remote Desktop under the hood. If you turn off Enhanced Session you use the basic Hyper-V console, that shows you that a user is really connected to the system.


Figure 3: The console in basic session mode correctly shows the logged user

It turns out that, with enhanced mode, you are not able to see the session that is started automatically, but the session is active. If you really want to verify what is happening, you can simply switch to basic mode.

Gian Maria.