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?
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=22.214.171.124, 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="126.96.36.199-188.8.131.52" newVersion="184.108.40.206"/> </dependentAssembly>
<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>
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…
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)
Sometimes users might have issues with connecting to TFS, either the web interface or through Visual Studio. Below are some of the commonly errors I see.
Sometimes you need to get the latest successful build and get the download path for the artifact, for e.g. some 3 part tools or as an input for other build jobs.