I had the pleasure of troubleshooting an issue that occurred on our build server after we tried to improve performance by parallelizing the build. We need to build the same project in several configurations, so we started running the dotnet publish command for each configuration in parallel, of course with a different output folder for each one.
Caching of NuGet packages can significantly speed up .NET builds in GitHub Actions, especially if your projects has many dependencies. The generic cache GitHub action used to be the only way to do that and I described how to configure it a while back in my article for DotNetCurry Magazine. However, recent versions of setup-dotnet GitHub action now have this functionality built in which makes the configuration even simpler.
The template I'm using for creating a new GitHub Actions workflow for .NET projects doesn't create any test and coverage reports, so that's usually the first thing I add to it. I've documented my approach in the past across two articles I've written for the DotNetCurry Magazine. But since the relevant instructions are interleaved with other topics and some details have changed since those articles were published, I decided to write this blog post with up-to-date information and focus only on this part of the workflow.
When I was looking into GitHub Actions, I found an example configuration for dependency caching that seemed wrong to me. It specified that a unique key for caching dependencies should be generated by hashing all files named package.lock.json in the repository. I would expect the *.csproj files to be used instead.
Since the introduction of GitHub Actions there's often no need any more to use an external CI/CD service. After I moved my blog repository from BitBucket to GitHub it was time to move my continuous deployment configuration from CircleCI to GitHub Actions as well.
Cyclomatic complexity is a simple code metric, commonly used to identify complex methods which are difficult to maintain and therefore good candidates for refactoring. It is one of the five code metrics built into Visual Studio 2017, but it isn't available for .NET Core and .NET Standard projects. Let's look at third party extensions which you can use instead.
When I wanted to replace my local TeamCity based deployment setup for my blog with a hosted one, I chose CircleCI based on its good support for private repositories in BitBucket and an abundant free offering. The migration process went surprisingly smooth, even though I had to change the technique I used for deploying to Azure since there's no Web Deploy on Linux.
At the end of November the second part of my Visual Studio video course was published. With that, all of the materials which I was recording during summer and early autumn are finally available for everyone to watch.
The introduction of diagnostic analyzers in Visual Studio 2015 significantly lowered the bar for development of custom static code analyzers. The supporting infrastructure makes it easy to have the same static analysis run after every commit as part of continuous integration on your build server - you just need to configure your Visual Studio projects correctly.
The new version of NDepend brought many new features; among them also integration with TeamCity build server. This convinced me to give it another closer look; evaluating how taking advantage of this can contribute to increasing code quality in larger development teams.
Writing a build script was only the first step in setting up continuous integration. In this follow-up post I describe how to configure TeamCity for Grunt and provide a couple of hints how to make it work even better.
Since my first DocPad project is slowly nearing completion, it was time to create a build script for it. I decided to use Grunt, which allowed me to achieve everything I wanted to: generate the static site, detect broken links in it, and deploy it to the web server.
I can recommend the book to anyone having TeamCity as their continuous integration server, as well as to those who are considering it as their first or new solution for continuous integration.
After a hardware upgrade I decided to switch from CruiseControl.NET to TeamCity for my personal continuous integration server to see for myself how they compare. Since I don't have all that many active projects, the free Professional Server License is a great option to try out all of the features without paying for it. At the same time it should give me enough insight to see whether it has enough advantages over free alternative(s) for the investment to make sense in a larger environment.
Last week I was configuring the build server to compile its first Visual C++ 2010 project. I took the approach of using MsBuild on the project file (.vcxproj) as I am already doing it with the .NET projects. This worked just fine on my development machine with Visual Studio 2010 installed. It soon turned out not to be as easy as I expected it to be.
Since version 1.5 CruiseControl.NET includes an FTP Task which can be used for uploading build results to a remote FTP server. Configuring it correctly requires some thought and at the moment there are very few helpful resources available.
Subversion and CruiseControl.NET can be invaluable tools in your .NET development process. There are many resources available to help you get started which I'll try to gather in this post along with some of my personal experiences.
Once you start putting CruiseControl.NET to production use you'll sooner or later encounter the need for custom build tasks. Unfortunately there is not much information available on development of custom tasks.
The 1.3.0.2918 build of CruiseControl.NET has an error in `msbuild.xsl` file which causes an XslLoadException to be thrown when trying to view the MSBuild output in the web dashboard.