When you have a TFS collection that has been running for a long time, as I do, you end with a lot of shelvesets.
The drawbacks of this is of course, (minor) storage, but it also affects upgrade time.
But instead of manually delete all the old obsoleted stuff manually, Powershell rescues us.
Powershell connection to VSTS
The previous sample scripts on this blog has been about how to use Powershell through the REST API on a on-premise TFS. I’ve got some question about how to connect to Visualstudio Online (VSTS).
All the samples can be modified to connect to VSTS.
Get XAML build info
Just a small followup on Getting latest build in PS as the link is related to vNext build.
But what about the old XAML build, if you still have this?
TFS 2018 released
Yesterday at Connect(), the latest version of TFS was released.
Some of the new things to mention are:
Build-in Wiki for your teams to create a single entry site for help and guides.
Git Forks, so you can have forks on your main branch
Large scale of Git support, what Microsoft calls GVFS, for large scale Git repositories.
TFS 2018 will no longer support XAML based builds and lab management (MTLM lab part).
Full release notes click here TFS 2018 rel notes
Download link for ISO TFS 2018 ISO
More info about the release will come… Stay tuned
Can you point me in the direction of the assembly?
In VS 2017 (15.4.2) When opening unittest files form previous version of VS, you can end up getting an error where it is unable to find the assembly in its correct version:
Could not load file or assembly ‘Microsoft.VisualStudio.QualityTools.Tips.UnitTest.ObjectModel, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
It seems that MS has made an mistake in their redirection of the assemblies.
It is possible to redirect assembly calls to previous version to use the latest version.
This can be done on app or machine level.
To learn more on this general topic see this link: Redirecting Assembly Versions
So to fix the error in VS 2017. Go to C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\ (default location)
and find the file devenv.exe.config
Change from:
<dependentAssembly>
<assemblyIdentity name="Microsoft.VisualStudio.QualityTools.Tips.UnitTest.ObjectModel" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="11.0.0.0-11.1.0.0" newVersion="15.0.0.0"/>
</dependentAssembly>
To
<dependentAssembly>
<assemblyIdentity name="Microsoft.VisualStudio.QualityTools.Tips.UnitTest.ObjectModel" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="11.0.0.0-14.1.0.0" newVersion="15.0.0.0"/>
</dependentAssembly>
Maintenance at its limits
Back in the days before Windows 8 and Server 2012, all the patches would quickly consume lots of disk space in the windows installer folder, due to caching of all the files, to make it possible if you needed to uninstall patches.
A common fix back then was to delete the contents, either manually or through some 3.part tools, which could cause inconsistency.
In win 8 and server 2012 Microsoft invented the Thrusted installer and TiWorker process to, among other stuff, maintain the WinSxS folder like cleaning up duplicated or orphaned files and compress the remaining folders.
In addition to that .Net precompiles its intermediate code into native machine code for the updated parts.
Sound pretty good ehh? Well it has some drawbacks…
Deploy artifacts without SMB
When doing release management one of the first step is to get the artifacts from your buildjob copied to a remote machine. TFS already have some buildin tasks like Windows machine File Copy or the Azure File Copy task
The Azure file copy task uses the Azure scripts to copy files to the Blob or to the VM itself( it actually copies the files through the Azure LOB storage)
The Windows Machine File copy is using robocopy so it is meant for copying locally through the SMB protocol. However you might be blocked by a firewall that wont allow SMB.
Then PowerShell comes to the rescue. (As always)
