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.
Last year when I started this blog I decided to keep the layout as simple as possible, hence all the posts were just added to the home page and to their own page. Over time as more posts were written the home page got larger and larger making it slower to load and more difficult to navigate. In order to improve this pagination of the home page was introduced.
Once again DocPad makes this very easy because all you have to do is add the DocPad-paged plugin and then update the documents you want to split. In the case of this blog only the index page needed to be split. The new index page now looks like this:
In order to make the paged plugin do its work the following 'properties' were added to the header:
- isPaged - Indicates that the document should be broken up into multiple pages.
- pageCollection - The collection from which the sub-documents that will fill up the current page are taken.
- pageSize - The number of sub-documents per page
Finally two buttons were added to the bottom of the page to naviage to he newer and the older posts.
A while ago I decided that it was time to add an archive page to the website so that there would be a place to get a quick overview of all the posts that I have written. Fortunately setting up an archive page with DocPad is relatively simple.
The first step to take was to add a new layout for the archive page.
The layout gets the list of all posts and iterates over them in chronological order. All the posts for one year are grouped together under a header titled after the year. In keeping with the layout of the rest of the site each post gets a title, the day and month and the tags that belong to that post. In order for this specific layout to work you will need to add the
moment node.js package
The layout and the CSS for the archive page is heavily based on the layout created by John Ptacek.
This release introduces NuGet packages that allow Visual Studio C# and WiX projects to share a common configuration including code analysis and strong naming capabilities and to generate one or more source files before building the project.
Both packages provide the ability to share a configuration between multiple projects in a Visual Studio solution. The shared configuration can contain items like Debug and Release settings, targeted .NET framework, code analysis settings and many other options.
Beyond that the C# NuGet package provides capabilities to:
AssemblyInfo.VersionNumber.cscontains the version numbers for the project as determined by nBuildKit from the versioning strategies provided. Currently supported are either a version number provided through an MsBuild project file or through GitHubFlowVersion. By allowing nBuildKit to generate the
AssemblyInfo.VersionNumber.csfile it is possible to automatically version the binaries the same way as all other artifacts, e.g. NuGet packages, installers, documentation etc. etc.. The version number is currently provided through the AssemblyVersionAttribute as
Major.Minor.0.0; through the AssemblyFileVersionAttribute as
Major.Minor.Patch.Build; and through the AssemblyInformationalVersionAttribute as the full semantic version.
AssemblyInfo.BuildInformation.cscontains information about the current build of the binaries. This includes the configuration, e.g. Release; the date and time that the binary was compiled and information describing the build number and the commit number that were used to generate the binaries.
AssemblyInfo.InternalsVisibleTo.cscontains the InternalsVisibleToAttribute values for any assemblies that should have access to the internals of the current assembly for purposes of unit testing.
AssemblyInfo.Company.cscontains the information describing the 'company' that created the binaries. The information includes the AssemblyCompanyAttribute and the AssemblyCopyrightAttribute.
- Generate a
CompanyInformation.cssource file that contains an internal static class providing constants for the company name and the company URL.
- Generate a
ProductInformation.cssource file that contains an internal static class providing constants for the name of the product.
- Generate an
app.manifestfile with the current project version number.
And the WiX NuGet package provides capabilities to
- Generate a
VersionNumber.wxiWiX include file that contains the version numbers for the application and the installer.
- Generate a
CompanyInformation.wxiWiX include file that contains the name and URL of the company that produces the product.
- Generate a
ProductInformation.wxiWiX include file that contains the name and description of the product.
The generation of all of these files can be enabled through a setting in the
settings.props file that is also used by the nBuildKit.MsBuild NuGet package
The documentation for this library can be found on the nBuildKit wiki