There have been a load on announcements about TFS, VSO and Visual Studio in general in the past couple of week, mostly at the Connect() event.
Just to touch on a few items
If you have not had a chance to have look at these features try the videos of all the sessions on Channel9, the keynotes are a good place to start. Also look, as usual, at the various posts on Brian Harry’s Blog. It is time of rapid change in ALM tooling
Whilst getting integration tests running as part of a Release Management pipeline within Lab Management I hit a problem that TCM triggered tests failed as the tool claimed it could not access the TFS build drops location, and that no .TRX (test results) were being produced. This was strange as it used to work (the RM system had worked when it was 2013.2, seems to have started to be issue with 2013.3 and 2013.4, but this might be a coincidence)
The issue was two fold..
Permissions/Path Problems accessing the build drops location
The build drops location passed is passed into the component using the argument $(PackageLocation). This is pulled from the component properties, it is the TFS provided build drop with a \ appended on the end.
Note that the \ in the text box is there as the textbox cannot be empty. It tells the component to uses the root of the drops location. This is the issue, as when you are in a network isolated environment and had to use NET USE to authenticate with a the TFS drops share the trailing \ causes a permissions error (might occur in other scenarios too I have not tested it).
Removing the slash or adding a . (period) after the \ fixes the path issue, so..
- \\server\Drops\Services.Release\Services.Release_18.104.22.16879 - works
- \\server\Drops\Services.Release\Services.Release_22.214.171.12479\ - fails
- \\server\Drops\Services.Release\Services.Release_126.96.36.19979\. - works
So the answer is add a . (period) in the pipeline workflow component so the build location is $(PackageLocation). as opposed to $(PackageLocation) or to edit the PS1 file that is run to do some validation to strip out any trailing characters. I chose the later, making the edit
$buildDirectoryParameter = [string]::Empty
# make sure we remove any trailing slashes as the cause permission issues
$BuildDirectory = $BuildDirectory.Trim()
$BuildDirectory = $BuildDirectory.Substring(0,$BuildDirectory.Length-1)
$buildDirectoryParameter = "/builddir:""$BuildDirectory"""
Cannot find the TRX file even though it is present
Once the tests were running I still had an issue that even though TCM had run the tests, produced a .TRX file and published it’s contents back to TFS, the script claimed the file did not exist and so could not pass the test results back to Release Management.
The issue was the call being used to check for the file existence.
As soon as I swapped to the recommended PowerShell way to check for files
it all worked.
I have been setting up some integration tests as part of a release pipeline. I am using TCM.EXE to trigger tests from the command line. Something along the lines
TCM.exe run /create /title:"EventTests" /collection:"http://myserver:8080/tfs” /teamproject:myteamproject /testenvironment:"Integration" /builddir:\\server\Drops\Build_188.8.131.525” /include /planid:26989 /suiteid:27190 /configid:1
I kept getting the error
‘A test run must be created with at least one test case’
Strange thing was my test suite did contains a number of test, and they were marked as active.
The issue was actually the configid it was wrong, there is no easy way to check them from the UI. use the following command to get a list of valid IDs
TCM.exe configs /list /collection:"http://myserver:8080/tfs” /teamproject:myteamproject
35 Windows 8.1 ARM
36 Windows 8.1 64bit
37 Windows 8.1 ATOM
38 Default configuration created @ 11/03/2014 12:58:15
39 Windows Phone 8.1
Your can now use the correct ID, not one you had to guess
I have a few old Visual Studio Online (VSO) accounts (dating back to TFSPreview.com days). We use them to collaborate with third parties, it was long overdue that I tidied them up; as a problem historically has been that all access to VSO has been using a Microsoft Accounts (LiveID, MSA), these are hard to police, especially if users mix personal and business ones.
The solution is to link your VSO instance to an Azure Active Directory (AAD). This means that only users listed in the AAD can connect to the VSO instance. As this AAD can be federated to an on-prem company AD it means that the VSO users can be either
- Company domain users
- MSA accounts specifically added to AAD
Either way it gives the AAD administrator an easy way to manage access to VSO. A user with a MSA, even if an administrator in VSO cannot add any unknown users to VSO. For details see MSDN. All straight forward you would think, but it I had a few issues.
The problem was I had setup my VSO accounts using a MSA in the form email@example.com, this was also linked to my MSDN subscription. As part of the VSO/AAD linking process I needed to add the MSA firstname.lastname@example.org to our AAD, but I could not. The AAD was setup for federation of accounts in the mycompany.com domain, so you would have thought I would be OK, but back in our on-prem AD (the one it was federated to) I had email@example.com as an email alias for firstname.lastname@example.org. Thus blocked the adding of the user to AAD, hence I could got link VSO to Azure.
The answer was to
- Add another MSA account to the VSO instance, one unknown to our AD even as an alias e.g. email@example.com
- Make this user the owner of the VSO instance.
- Add the firstname.lastname@example.org MSA to the AAD directory
- Make them an Azure Subscription administrator.
- Login to the Azure portal as this MSA, once this was done the VSO could be linked to the AAD directory.
- I could then make an AAD user (email@example.com) a VSO user and then the VSO owner
- The firstname.lastname@example.org MSA could then be deleted from VSO and AAD
- I could then login to VSO as my email@example.com AAD account, as opposed to the old firstname.lastname@example.org MSA account
Simple wasn’t it!
We still had one problem, and that was email@example.com was showing as a basic user in VSO, if you tried to set it to MSDN eligible flipped back to basic.
The problem here was we had not associated the AAD account firstname.lastname@example.org with the MSA account email@example.com in the MSDN portal (see MSDN).
Once this was done it all worked as expected, VSO picking up that my AAD account had a full MSDN subscription.
I have posted before about using Release Management with Lab Management network isolation. They key is that you must issue a NET USE command at the start of the pipeline to allow the VMs in the isolated environment the ability to see the TFS drops location.
I hit a problem today that a build failed even though I had issued the NET USE.
I got the error
Package location '\\store\drops\Sabs.Main.CI\Sabs.Main.CI_184.108.40.20630\\' does not exist or Deployer user does not have access.
Turns out the problem was I had issued the NET USE as \\store.blackmarble.co.uk\drops not \\store\drops it is vital the names match up. Once I changed this my NET USE all was OK
I don’t normal do posts that are just re-posts of TFS announcements, it is much better to get the information first hand from the original post, but this one is significant for us in Europe…
Up to now there has been a barrier to adoption of VSO that the underlying data will be hosted in the USA. Now there are all the usual Azure Microsoft guarantees about data security, but this has not been enough for some clients for legal, regulatory or their own reasons. This has made VSO a non-starter for many European’s where it at first appears a great match.
As of today you can now choose to host your new VSO account in Europe (Amsterdam data center). It won’t remove everyone's worries of cloud hosting, but certainly is a major step in the right direction from a European point of view, addressing many regulatory barriers.
Unfortunately we will have to wait a few sprints to be able to migrate any existing VSO instances, but you can’t have everything in one go!
For the full details have a look at Brian Harry’s and Jamie Cool’s posts
There has for a long time been an issue that when you try to add a new activity to the toolbox when editing a TFS build workflow Visual Studio can crash. I have seen it many times and never got to the bottom of it. It seems to be machine specific, as one machine can work while another supposedly identical will fail, but I could never track down the issue.
Today I was on a machine that was failing, but …
But I found a workaround in a really old forum post. The workaround is to load the IDE from the command line with the /safemode flag
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe /safemode
Once you do this you can edit the contents of your toolbox without crashes, and also your template if you wish. The best part is that once you exit the IDE and reload it as normal your new toolbox contents are still there.
Not perfect, but a good workaround
Whilst configuring a Release Management 2013.3 system I came across a confusing error. All seemed OK, the server, client and deployment agents were all installed and seemed to be working, but when I tried to select a build to deploy from both the Team Projects and Build drop downs were empty.
A check of the Windows event log on the server showed the errors
The underlying connection was closed: An unexpected error occurred on a send
The handshake failed due to an unexpected packet format
Turns out the issue was an incorrectly set value when the Release Management server was configured. HTTPS had been incorrectly selected, in fact there was no SSL certificate on the box so HTTPS could not work
As this had been done in error we did not use HTTPS at any other point in the installation. We always used the URL http://typhoontfs:1000 . The strange part of the problem was that the only time this mistake caused a problem was for the Team Project drop down, everything else seemed fine, clients and deployment agents all could see the server.
Once the Release Management server was reconfigured with the correct HTTP setting all was OK
If you want to get your TFS build process to product SSRS RDL files you need to call the vsDevEnv custom activity to run Visual Studio (just like for SSIS packages). On our new TFS2013.3 based build agents this step started to fail, turns out the issue was not incorrect versions of DLLs or a some badly applied update, but that the license for Visual Studio on the build agent had expire.
I found it by looking at diagnostic logs in the TFS build web UI.
To be able to build BI project with Visual Studio you do need a licensed copy of Visual Studio on the build agent. You can use a trial license, but it will expire. Also remember if you license VS by logging in with your MSDN Live ID that too needs to be refreshed from time to time (that is what go me), so better to use a product key.
We have for a long time used the TFSVersion custom build activity to stamp all our TFS builds with a unique version number that matches out build number. However, this only edits the AssemblyInfo.cs file. As we are now building more and more Windows 8 Store Apps we also need to edit the XML in the Package.appxmanifest files used to build the packages too. Just like a Wix MSI project it is a good idea the package version matches some aspect of the assemblies it contains. We need to automate the update of this manifest as people too often forget to increment the version, causing confusion all down the line.
Now I could have written a new TFS custom activity to do the job, or edited the existing one, but both options seemed a poor choice. We all know that custom activity writing is awkward and a pain to support going forward. So I decided to use the hooks in the 2013 generation build process template to just call a custom PowerShell script to do the job.
I added a PreBuildScript.PS1 file as a solution item to my solution.
I placed the following code in the file. It uses the TFS environment variables to get the build location and version; using these to find and edit the manifest files. The only gotcha is files on the build box are read only (it is a server workspace) so the manifest file has to be set it to allow it to be written back too.
# get the build number, we assume the format is Myproject.Main.CI_220.127.116.1190
# where the version is set using the TFSVersion custom build activity (see other posts)
$buildnum = $env:TF_BUILD_BUILDNUMBER.Split('_')
# get the manifest file paths
$files = Get-ChildItem -Path $env:TF_BUILD_BUILDDIRECTORY -Filter "Package.appxmanifest" -Recurse
foreach ($filepath in $files)
Write-Host "Updating the Store App Package '$filepath' to version ' $buildnum '"
# update the identity value
# set the file as read write
Set-ItemProperty $filepath.Fullname -name IsReadOnly -value $false
Note that any output sent via Write-Host will only appear in the diagnostic log of TFS. If you use Write-Error (or errors are thrown) these messages will appear in the build summary, but the build will not fail, but will be marked as a partial success.
Once this file was checked in i was able to reference the file in the build template
The build could not be run and got my Windows 8 Store packages with the required version number