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....

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....