Uncategorised

The registration link for Microsoft UK TechDays Online is now live. This is a 5 day event live broadcast from the Microsoft Campus in Reading. You will be able to view the sessions live at https://channel9.msdn.com/ The themes for each day are: Monday, 12 September: Explore the world of Data Platform and BOTs Tuesday, 13 September: DevOps in practice Wednesday, 14 September: A day at the Office! Thursday, 15 September: The inside track on Azure and UK Datacenter Friday, 16 September: Find out more about Artificial Intelligence I am doing a session on the Thursday on Azure DevTest Labs....

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