The TFS team has released a security update for TFS 2015 and 2017, that fixes issues with cross-site scripting.
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.
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.
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).
More info about the release will come… Stay tuned
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=184.108.40.206, 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
<dependentAssembly> <assemblyIdentity name="Microsoft.VisualStudio.QualityTools.Tips.UnitTest.ObjectModel" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/> <bindingRedirect oldVersion="220.127.116.11-18.104.22.168" newVersion="22.214.171.124"/> </dependentAssembly>
<dependentAssembly> <assemblyIdentity name="Microsoft.VisualStudio.QualityTools.Tips.UnitTest.ObjectModel" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/> <bindingRedirect oldVersion="126.96.36.199-188.8.131.52" newVersion="184.108.40.206"/> </dependentAssembly>
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…