I have been slowly working on rebuilding a web application from ASP.Net MVC into a SPA application over the last six months. The timescale of this work has been a blessing and a curse. It is a blessing because there has been an amazing churn in the client frameworks, build pipelines and current best practices so I get to learn a lot of new things. This is directly linked to the curse however as it makes it very difficult to rewrite an existing system and keep up with that rate of change.

I want to share what I have learnt about module loaders as part of this journey. It is new to me so please shout out any inaccuracies in the comments.

One of the benefits of work items in VSTS/TFS is the ability to put metadata into your project system. Associating work items with automated builds is a good example of this. The XAML build system in VSTS/TFS has a handy feature of linking the build number against associated work items as a part of the build process. Unfortunately, there is no out of the box implementation to achieve this in build vNext.

The XAML build workflow stores build numbers in the Microsoft.VSTS.Build.IntegrationBuild field to link a work item to the build. The IntegrationBuild field is only visible by default in the Bug work item template however the field still exists for PBI and Task work items. You can modify the PBI and Task work item templates however to make this field visible.

We can add the functionality for linking work items to builds by executing some PowerShell during a build that will populate the IntegrationBuild field. As this will be a custom script we can also add some additional functionality.

I’ve been sitting on this one a while and I think this library is ready for some consumption. I created ModelBuilder earlier this year partly as a fun project, but also so that I could get some better test data to work with when doing test automation in C#.

The library provides an easy way to build model classes with random data where the data is better quality that just Guid values for string properties or Environment.TickCount for integers. It also has a lot of extensibility points so that you can customise the model generation.

You can get ModelBuilder from NuGet by running Install-Package ModelBuilder. The following is the documentation for the first release.

Writing release documentation is one of those tasks that you need to do, but nobody wants to do it. We want the ability to automate the generation of documentation as much as possible to remove both manual labour and human error.

My team uses VSTS to manage the planning and delivery of software and we have defined it as the source of truth about our software from requirements to release. This means that (assuming good process is followed) VSTS contains all the information about the history of the product. This is the perfect source of information to produce release notes.

I’ve been rebuilding my Octopus Deploy infrastructure to make use of the new VM, network and security support in Azure. Having to install an Octopus Tentacle on each target machine is obviously cumbersome and PowerShell is a really good answer.

The Octopus Deploy documentation already contains the bulk of the work for the script. I did find however that the netsh called failed because PowerShell didn’t like it being quoted.

In order to streamline this process as much as possible, I want the script to also download the latest tentacle MSI, install it and then clean up.

A couple of years ago I posted a second version of recommended reading for developers. At the time I was training up my team on some of the newer development features, namely the new async support in .Net. Since then I have come across two pitfalls that can catch developers off guard.

For some background, we need to understand what the compiler does when it processes the async and await keywords. The async keyword only affects the local method, not its callers or callee’s. The compiler adds a state machine into the method so that it can track what happens before and after hitting an awaited task. For example, all variables (and parameters) declared before the awaited task must be stored so that the continuation has access to them. The continuation is the code that executes after the awaited task. The continuation may or may not execute on the thread that originally invoked the method.

One thing to note here is that using the async keyword on a method that doesn’t have a continuation adds a performance hit because the compiler is adding an unnecessary state machine into the method. There would be no continuation either because there is no awaited task or no code blocks after the only awaited task. To avoid the performance hit of the state machine, a simple pass-through style method should not use async.

I’m working through a support issue with Microsoft to do with Azure Service Bus. One potential issue raised was that my application is running as 32bit rather than 64bit. When I checked it out, the Prefer 32 bit setting was enabled on the project. This means that the exe’s will be running as x86 even though it is running on an x64 machine.

All the way back in 2009 I wrote a little console application that assisted with renaming a Visual Studio project and/or namespace. It was handy in that it took into consideration the solution being under source control with TFS. Over the years I have been using TF source control less and Git more. On the odd occasion I have also used this script for solutions that are not bound in source control.

I have refactored the script to take out the TF integration, remove the logging that was just causing a whole lot of white noise and to add in a few more out of the box exclusions for directories to skip in the process.

I’ve started converting projects from TFSC to Git in VSO. As part of this process I am working out the best way to achieve semantic versioning. GitVersion looks like a great product to assist in this. By default however the version numbers that it produces are not supported by NuGet.

The particular problem with NuGet version numbers can be read in more detail here.

The previous two posts (here and here) have looked at a POC for returning dynamic data from Web API and then adding a defined schema to a semi-dynamic object. This post is the next POC that looks at how to POST that data to the Web API.

The design goals are similar to the previous POCs. There is a type that has some known properties and then contains JSON serialized metadata for all the remaining dynamic properties. The storage and retrieval of the metadata should conform to some known schema for that metadata.

The code here uses JObject from Newtonsoft.JSON as the mechanism of making the dynamic data available to the controller action. We then need to separate out the known properties from the metadata properties and convert all of them to the correct type.