Roundup #28: MinVer, API Discovery, Dependabot, Repository Pattern, Typescript

Here are the things that caught my eye this week.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.



A minimalistic .NET package for versioning .NET SDK-style projects using Git tags.

When you want to release a version of your software, whether it’s a pre-release, RTM, patch, or anything else, simply create a tag with a name which is a valid SemVer 2.0 version and build your projects. MinVer will apply the version to the assemblies and packages. (If you like to prefix your tag names, see the FAQ.)



REST Fest 2018: Kin Lane

Kin Lane (API Evangelist) – ”API Discovery in the Real World is Complicated” – 28 September 2018

REST Fest 2018 \ Kin Lane (API Evangelist) \ 2018 Keynote from REST Fest on Vimeo.



Dependabot pulls down your dependency files and looks for any outdated or insecure requirements.

If any of your dependencies are out-of-date, Dependabot opens individual pull requests to update each one.

You check that your tests pass, scan the included changelog and release notes, then hit merge with confidence.



Stop Using Repository Pattern With an ORM

In this post I’m going to list some reasons  suggested for using repository pattern. Then we’re going to see if these reasons really needs these kind of patterns to be solved. Then I’m going to propose other alternatives for solving  these problems.



dotJS 2018 – Anders Hejlsberg

How do you define and implement a static type system for a dynamic language like JavaScript, and why would you even care to? Anders explores how TypeScript came to be, how it differs from classic type systems, and how it can be beneficial even if you don’t like types.

If you’re not on the TypeScript train yet, why not? But really, it might be worth a watch if you aren’t.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Using Date Version Numbers for Assemblies in TeamCity

Date Version Number in TeamCityIn some projects, I use the AssemblyInfo Patcher build feature to modify the AssemblyInfo.cs’s version information.  Mainly I was just using a static version with the %build_number% suffixed at the end.  Something like 1.2.3.%build_number%.  However, I decided to go with a date version number of YYYY.MM.DD.%build_number%


The first thing that caused me an issue was there is no existing system or environment variables defined that provide you with date parts.  I figured this by adding a new build step for creating an environment variable using Service Messages.

Service messages are specially constructed pieces of text that are used to pass commands/information about the build from the build script to the TeamCity server.

To be processed by TeamCity, they need to be written to the standard output stream of the build, i.e. printed or echoed from a build step. It is recommended to output a single service message per line (i.e. divide messages with newline symbol(s))

What this allowed me to do was create a build step in PowerShell and use Write-Host to output a service message:

Write-Host "##teamcity[setParameter name='env.BUILD_DATE' value='$([DateTime]::Now.Year.ToString() + "." + [DateTime]::Now.Month.ToString() + "." + [DateTime]::Now.Day.ToString())']"

This will create a new environment variable that I can use called %env.BUILD_DATE%

AssemblyInfo Patcher

As mentioned, I use this build feature to modify the AssemblyInfo.cs, however, I immediately ran into an issue.

AssemblyInfo Patcher should be used with the automatic checkout only: after this build feature is configured, it will run before the first build step. TeamCity will first perform replacement in the files found in the build checkout directory and then run your build.

The issue is that the AssemblyInfo patcher is run before the first build step which is setting the environment variable.  Meaning I cannot use the environment variable in the AssemblyInfo patcher.

Snapshot Dependencies

What I decided to do was create a new build configuration that only contained one build step.  That build step would be the PowerShell above which sets the environment variable.  Then I would link my existing build configuration to this new build configuration.  In TeamCity these are defined as SnapShot Dependencies.

Build configurations linked by a snapshot dependency will use the same snapshot of the sources. The build of this configuration will run after all the dependencies are built. If necessary, the dependencies will be triggered automatically.

Dependency Properties

Once I had my dependencies defined, you can use build parameters from linked dependencies.  Now in the assembly patcher, I can use the environment variable by:



Practical ASP.NET Core SignalR Overview

Practical ASP.NET Core SignalRASP.NET Core SignalR is an excellent way to add real-time functionality to your web applications.  You may be wondering, what exactly is real-time web functionality and what problem does that solve?

Here’s an overview of what problems SignalR solves, and how it does it using various technologies.

This blog post is apart of a course that is a complete step-by-setup guide on how to build real-time web applications using ASP.NET Core SignalR. By the end of this course, you’ll be able to build real-world, scalable, production applications using the tools and techniques provided in this course.

What you’ll learn:

  • Creating ASP.NET Core SignalR Hubs
  • Connecting to Hubs using JavaScript Clients
  • Scaling your application using Redis and Azure

If you haven’t already, check out the prior sections of this course.

  1. Course Overview


ASP.NET CoreSignalR Overview

ASP.NET Core SignalR: Problem Space

ASP.NET Core SignalR: Push

ASP.NET Core SignalR: Summary


Get The Course!

If you want all the content right now, you can access the full course now by enrolling for free on Teachable.  Otherwise stay tuned to this blog and my YouTube Channel for all the content in the coming weeks.