I recently posted on how we were versioning our Nuget packages as part of a release pipeline. In test we noticed that the packages being produced by this process has an extra folder inside them. We expected there to be a netcore50 folder, but not a .NETCore50 folder. Strangely if we build the package locally we only saw the expect netcore50 folder. The addition of this folder did not appear to be causing any problem, but I did want to find out why it had appeared and remove it as it was not needed. ...

Background We are currently packaging up a set of UX libraries as NuGet packages to go on our internal NuGet server. The assemblies that make up the core of this framework are all in a single Visual Studio solution, however it makes sense to distribute them as a set of NuGet packages as you might not need all the parts in a given project. Hence we have a package structure as follows… ...

Do you have repeating blocks in your VSTS release pipelines? I certainly do. A common one is to run a set of functional test, so I need to repeatedly … Deploy some test files to a VM Deploy a test agent to the VM – IMPORTANT I had not realised you can only run one test run against this deployed agent. You need to redeploy it for the next run Run my tests … and repeat for next test type/configuration/test plan/DLL etc. In the past this lead to a lot of repeat tasks in my release pipeline, all very messy. ...

I have just released 1.4.7 of the release notes VSTS extension. This provides a new advanced options that allows you to switch the authentication model. The default remains the same i.e. use a personal access token provided by the server, but you have the option to enable use of the ‘defaultcredentials’ (via the advanced properties). If this is done the account the build agent is running as is used. Hopefully this should fix the 401 issues some people have been seeing when using the task with on-prem TFS. ...

I use a virtual NAT Switch to allow my VMs to talk to the outside world. The way I do this is documented in this post, based on the work of Thomas Maurer. The upgrade to Windows 10 Anniversary messed this up, just seemed to loose the virtual network completely, VMs failed to start with invalid configurations and would not even start. I had to recreate my NATSwitch using Thomas’s revised instructions, but I did have an problem. The final ‘New-NetNat’ command failed with a ‘The parameter is incorrect.’ error. I think the issue was that there was debris left from the old setup (seems Microsoft removed the NatSwitch interface type). I could find no way to remove the old NATSwitch as it did not appear in the list in PowerShell and there is no UI remove option. So I just ended up disabling it via the UI and this seemed to do the trick ...

I have been using the Microsoft Band (both version Band1 and Band2) since they came out, and been reasonably happy. However, a year or so on my issues with it have remained the same Poor battery life, I can live with charging it each day, but even with GPS Power-saver mode on I can’t go for any exercise over about 4 hours (bit of an issue for longer bike rides) It is not waterproof, so no swimming (and worried doing the washing up) Also there seem to be some build issues with the robustness of the Band2. I had to get mine replaced due to it not accepting recharging and the forums seems to report people suffering problems with the wrist strap splitting. That said, the warrantee service seems excellent, no complaints there, mine was swapped without any issue in a couple of days ...

The RadioTFS show that I was the guest on has just been published at http://radiotfs.com/Show/117. If you don’t listen to RadioTFS why not? It is a regular podcast (as you can see with over 100 episodes) on all things TFS and VSTS. A great way to keep up what is new in the technology space. Links to this and all my other recorded sessions can be found here

Just published a new VSTS extension with a couple of tasks in it. The aim to to help formalise the end of a release process. The tasks Allow you to set the retension ‘keep forever’ flag on a build (or all builds linked to a release) Update increment a build variable e.g. all or part of a version number, in a build (or all builds linked to a release) The first just replicates functionality I used to have in house for builds ...

I have been using Visual Studio Code for PowerShell development, but got a bit behind on reading release notes. Today I just realised I can make my Integrated Terminal a Code a PowerShell instance. In File > Preferences > user Settings (settings.json) enter the following // Place your settings in this file to overwrite the default settings { // The path of the shell that the terminal uses on Windows. "terminal.integrated.shell.windows": "C:\\windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe" } Now my terminal is a PowerShell instance, and you can see it has loaded by profile so POSH Git is work as well ...

I recently posted on my development process for VSTS Extensions, it has been specifically PowerShell based build ones I have been working on. During this development I have come across a few more gotcha’s that I think are worth mentioning 32/64 bit The VSTS build agent launches PowerShell 64bit (as does the PowerShell command line on dev PC), but VSCode launches it 32bit. Whilst working my StyleCop extension this caused me a problem as StyleCop it seems can only load dictionaries for spell checking based rules when in a 32bit shell. So my Pester tests for the extension worked in VSCode but failed at the command line and within a VSTS build ...