This release adds the following features
- 91: MsBuild.Projects: Common.props should do a more extensive search for settings.props
- 90: MsBuild: Allow pushing symbols via NuGet enhancement
- 89: MsBuild: Allow assembly versioning to be more custom defined.
- 87: MsBuild: Rename template files to have normal extension
- 86: MsBuild: Rename the DirMsBuildShared, DirMsBuildExtensions and DirMsBuildTemplates properties enhancement
- 85: Unable to build projects which have a mixture of target frameworks
- 83: MsBuild: Allow PreCleanScripts and PreCompilationScripts to define their own properties
- 82: MsBuild: Update the Sample custom version files to match the current version gathering capabilities
- 80: MsBuild: Combine top-level build.msbuild, deploy.msbuild and shared.locatenbuildkit.msbuild
- 78: MsBuild: Automatically include NuGet dependencies if nuspec is in same directory as project
- 72: MsBuild: Define default directory paths only in settings.props file
- 68: Improve inline documentation of settings.props file
- 66: MsBuild: Provide initialization/installation scripts for an empty workspace
- 55: MsBuild: Allow assembly copyright to be more custom defined
- 22: MsBuild: Allow each file to have their own base directory when creating ZIP archives
- 19: MsBuild.Projects: Provide scripts for Visual Basic projects
And fixes the following issues:
- 92: MsBuild.Projects: GetVersion, VcsInfo and Generate files also run when they're disabled in the settings.props file
- 88: MsBuild.Projects: Excessive NuGet restore of global packages
- 84: Not compatible with ncrunch
- 54: MsBuild: First space trimmed from release note content
Finally the following tasks were completed:
- 7: MsBuild: Set up tests
This release introduces the ability to mix custom build steps with the default provided ones in any order that is desired. On top of that additional changes were made that now make it possible to build multiple Visual Studio solutions in a specific order.
Finally the user can provide one or more scripts that will be called if the build or the deploy process fails. These scripts can be used to clean-up resources or provide notification on build failure. Do note that any failure in these scripts will lead to the immediate termination of the process.
As part of a new project to create a Jenkins CI server on Azure I am writing a set of powershell scripts to control virtual machines on Azure. For this project the plan is to use virtual machine (VM) images as a template for an 'immutable server' that will contain the Jenkins instance.
Now the actual server isn't really 'immutable' given that the jenkins instance will update, add and delete files on the hard drive which will obviously change the state of the server. As such the immutable idea isn't applied to the whole server but more to the configuration part of the server. The idea being that the configuration of the server will not be changed once the server is put in production. Any configuration changes (e.g. a new version of Jenkins) will be done by creating a new image, spinning up a new server based on that image and then destroying the old server and replacing it with the new one.
So in order to achieve this goal the first step will be to build an image with all the required software on it and then verify that this image has indeed been created correctly.
To create the image we first obtain a certificate that can be used for the WinRM SSL connection between the Azure VM and the local machine that is executing the creation scripts. You can either get an official one or you can use a self-signed certificate (which is obviously less secure). Two things of interest are:
- The certificate needs to have an exportable private key because otherwise it cannot be used for the WinRM connection.
- The certificate needs to be named after the connection that you expect to make. For a connection to an Azure VM this will most likely be something like
Once the certificate is installed in the user certificate store we can create a new virtual machine from a given base image, e.g. a Windows 2012 R2 server image. The following powershell function creates a new windows VM with a WinRM endpoint with the certificate that was created earlier. Note that the
New-AzureVM function can create resource and storage groups for the new VM if you don't specify a storage account and a matching resource group.
Once the VM is running a new Powershell remote session can be opened to the machine in order to start the configuration of the machine. Note that this approach only seems to be working for
https connections because the
Get-AzureWinRMUri function only returns the
https URI. Hence the need for a certificate that can be used to secure the connection.
The next step is to copy all the installer files and configuration scripts to the VM. This can be done over the remoting channnel.
Once all the required files have been copied to the VM the configuration of the machine can be started. This can be done in many different ways, e.g through the use of a configuration management tool or just via the use of plain old scripts. When the configuration is complete and all the necessary clean-up has been done the time has come to turn the VM into an image. Before doing that a Windows machine will have to be sysprepp'ed so that there are no unique identifiers in the image (and thus in the copies).
In order to sysprep an Azure VM it is necessary to execute the sysprep command through a script on the VM because sysprep fails if the command is given directly through the remoting channel. The following function creates a new Powershell script which invokes sysprep, copies that to the VM and then executes that script. Once sysprep has completed running the machine will be turned off and an image can be created.
The next step is to test the new image in order to verify that all configuration changes have been applied correctly. The explanation of how the testing of an virtual machine image works is a topic for the next blog post.
The build server that is being used to build the packages for nBuildKit is AppVeyor. AppVeyor is an Continuous Integration system in the cloud. The way AppVeyor works is that every time a commit occurs in a GitHub project AppVeyor is notified. AppVeyor then spins up a new clean virtual machine (VM) on which your build scripts are executed. Once the build is done the VM is terminated and thrown away. This way there is no way that the changes made to the build environment by a build will influence future builds.
For nBuildKit two builds were configured. The first configuration is the standard continuous integration build which generates the version numbers and templates and then creates the NuGet packages. As the final step the build artefacts are archived for later use by the second build configuration. For this configuration no special settings are required other then to tell AppVeyor to store the artifacts.
The second build configuration handles the delivery of the artefacts. This configuration gathers the build artefacts from the latest build of the first build configuration, tags the revision that was build and then pushes the NuGet packages to NuGet.org and marks the given commit as a release in GitHub.
For this second configuration a few tweaks need to be made to the environment before the build can be executed. The first thing to do is to install the GitHub-release application which provides an easy way to push release information to github. A simple Powershell script is used to set-up this part of the environment:
Once all the required tools are installed the artefacts of the selected continuous integration build need to be downloaded and placed in the correct directories. For that yet another Powershell script is used:
Once all the artefacts are restored the delivery process can be executed. For nBuildKit the delivery process is executed by nBuildKit itself in the standard dogfooding approach that is so well known in the software business.
This release introduces a version provider using GitVersion and a custom version provider that can be implemented by a user. On top of that the nBuildKit.MsBuild.Projects.Common and nBuildKit.MsBuild.Projects.Common.Net packages have been merged with the C# and WiX packages.