Tech Tips

The Problem The documentation for the VSTS WIKI suggests you can embed a video in a VSTS WIKI using the markdown/HTML``` Problem is that this does not seem to work, the MP4 just does not appear, you get an empty video player. However, if you swap to a full URL it does work e.g. ### The Workaround The workaround is to either place the MP4 file in some URL accessible location e.g. some Azure web space (not really addressing the problem), or more usefully use the [VSTS API to get the file](https://docs.microsoft.com/en-us/rest/api/vsts/git/items/get?view=vsts-rest-4.1) out the repo that backs the WIKI. The format of the HTML tag becomes``` <video src="https://vstsinstance.visualstudio.com/MyTeamProject/\_apis/git/repositories/MyTeamProject.wiki/Items?path=\_media%2Fvstswiki\_high.mp4 width=400" controls> </video> ```This will get the current version of the file on default branch, you can add extra parameters to to specify versions and branches if required as per the [API documentation](https://docs.microsoft.com/en-us/rest/api/vsts/git/?view=vsts-rest-4.1). So not a perfect solution as you have to think about branches and versions, they are not handled automatically, but at least it does work

When you want to register a build agent with VSTS, you use the VSTS instance’s URL and a user’s Personal Access Token (PAT). Whilst doing this today I connected to the VSTS instance OK but got the error “Agent pool not found”.when I was asked to pick the agent pool to add the new agent to. As the user who’s PAT I was using was a Build Administrator I was a bit confused, but then I remembered to check their user access level. It was set to Stakeholder, once this was changed to Basic I was able to register the agent without use. ...

I have just rebuilt my first generation Surface Book from our company standard Windows image. These images are used by all our staff all the time without issue (on Surface and Lenovo devices), so I was not expecting any problems. I used to rebuild my PC every 6 months or so, but got out the habit when I moved to a model I could not swap the hard drive out of as backup during the process (using a new disk for new install). I got around this by using Disk2VHD, not quite as good as I can’t just swap the disk back in, but I won’t have lost any stray files, even though I always aim to keep data in OneDrive, Source Control or SharePoint, so it should not been an issue anyway. ...

Updated 3 July 2018 - A colleague, Andy Davidson, suggested mRemoteNG as an alternative tool to this address this issue. mRemoteNG also has the advantage that it support most major remoting technologies not just RDP, so I am giving that a try for a while. This is one of those post I do mostly for myself so I don’t forget how I did something, it is all based on answers on SuperUser.Com, I can claim no credit I have a SurfaceBook (first generation) and when I am in the office it is linked to an external monitor, with a different lower DPI, via a dock. If I use Remote Desktop (MSTSC) as built into Windows 10, I can drag sessions between the two monitors and the DPI shift is handled OK. However, if I use my preferred tool Remote Desktop Manager 2.7 (as it allow me to store all my commonly used RDP settings) I am in DPI hell. I either get huge fonts or microscopic ones. This is bad whether working on the single high DPI laptop screen work with an external screen. As the SuperUser.Com post states the answer is to change the compatibility settings for the manager by right clicking on the file “C:Program Files (x86)MicrosoftRemote Desktop Connection ManagerRDCMan.exe”, selecting compatibility, change high DPI settings, and unchecking high DPI setting override Once this was done, I have readable resolutions on all screens. Why did I not do a better search months ago? ...

Whilst writing some training material for VSTS I hit a problem creating a TFVC workspace. I was using VS2017, linking a TFVC Repo to a local folder. I was connecting to the VSTS instance using an MSA. In Team Explorer, when I came to do a ‘Map & Get’ to map the source locations I got a ‘TF14061: The workspace ws_1_18;Project Collection Build Service does not exist’ error Strange error, which I could see no obvious reason for. Turns out the work around was just to press the ‘Advanced’ link/button and accept the defaults ...

I recently, whilst changing a CI/CD release pipeline, updated what was previously a private version of a VSTS extension in the VSTS Marketplace with a version of the VSIX package set to be public. Note, in my CI/CD process I have a private and public version of each extension (set of tasks), the former is used for functional testing within the CD process, the latter is the one everyone can see. So, this meant I had two public versions of the same extension, confusing. ...

Whilst trying to install an MSI package we kept getting the errors 2755 and 1632 ‘The Temp folder is on a drive that is full or is inaccessible’. After much fiddling we found the problem was that the %systemroot%installer folder was missing. Once this was manually re-added the MSIs installed without a problem. The actual TEMP folder setting was a red herring

My existing VSTS CI/CD process has a problem that the deployment of a VSTS extension, from the moment it is uploaded to when it’s tasks are available to a build agent, is not instantiation. The process can potentially take a few minutes to roll out. The problem this delay causes is a perfect candidate for using VSTS Release Gates; using the gate to make sure the expected version of a task is available to an agent before running the next stage of the CD pipeline e.g waiting after deploying a private build of an extension before trying to run functional tests. The problem is how to achieve this with the current VSTS gate options? ...

I am currently looking at the best way to migrate a large legacy codebase from TFVC to Git. There are a number of ways I could do this, as I have posted about before. Obviously, I have ruled out anything that tries to migrate history as ‘that way hell lies’; if people need to see history they will be able to look at the archived TFVC instance. TFVC and Git are just too different in the way they work to make history migrations worth the effort in my opinion. ...

Background Having automated builds is essential to any good development process. Irrespective of the build engine in use, VSTS, Jenkins etc. you need to have a means to create the VMs that are running the builds. You can of course do this by hand, but in many ways you are just extending the old ‘it works on my PC – the developer can build it only on their own PC’ problem i.e. it is hard to be sure what version of tools are in use. This is made worse by the fact it is too tempting for someone to remote onto the build VM to update some SDK or tool without anyone else’s knowledge. ...