In-Memory Caching with Foundatio

In-Memory CachingI was recently looking for a simple in-memory caching library that sat on top of ConcurrentDictionary.  I didn’t have many requirements other than it needing to be thread safe and and had some expiry policy built-in.  I’ve used .NET MemoryCache before, but figured there likely had to be something simple else already built.

My search led me to Foundatio:

Pluggable foundation blocks for building distributed apps.

Turns out Foundatio was created for building Exceptionless.  I’ve blogged about Exceptionless before, which is a real-time error and logging .NET and Javascript.

Basics

Caching in it’s various forms (in-memory, distributed) is simply about storing a copy of the data in a way that improves performance.  This could be data from a web service, database, or any other call that involves reading data that rarely changes but is read/queried often.

Foundatio

First thing will be to get the latest NuGet package.

PM> Install-Package Foundatio

There are many other components that Foundatio provides besides Caching, such as: Queues, Locks, Messaging, Jobs, File Storage, Metrics and Logging.  I haven’t dug into any of these other areas yet, but once I do, you can expect a blog post.

In-Memory Caching Demo

As with most of my posts, all the following code is available as a demo application on GitHub.

This demo console app is going to show currency exchange rate between USD and CAD for a given day.

Since historical exchange rates don’t change, there is no point in making an HTTP call for a day that was already queried.

Also, one really cool feature I’ll show, is that you can set the max number of items in your cache.

So for this demo, I’m only going to keep the last 3 exchange rates by date in cache.

First we can start off by creating a new instance of an InMemoryCacheClient and setting it’s MaxItems property to 3.

Next, I want to create a method that is going to query for the exchange rate, but before it does, I want to check the cache to see if it exists.

The key for our cached object is going to be the date.  If the key does not exist in the cache, then we will make our HTTP call, get the results and cache it.

Now to write this all up, I’m going to take a date as input from the console application and have it invoke our GetCurrencyRate(DateTime).

Result

Now when we run our application, we can see that if we request the same date, within the last 3 requests, we will hit the cache instead making our HTTP call.

result

  1. Requested 2016-01-01, 2016-01-02, 2016-01-03, all of which were fetched from HTTP service.
  2. Requested 2016-01-01 again, which was pulled from cache.
  3. Requested a new date 2016-01-04 which was fetched from the HTTP service.
  4. Requested 2016-01-02 again, however since it is no longer the last 3 requested (2016-01-03, 2016-01-01, 2016-01-04) it has to fetch from the HTTP service.

More

There are other interesting CacheClient’s such as a hybrid Redis + InMemory cache client that I’m looking forward to exploring in Foundatio.

Let me know if you have any comments related to Foundatio or other caching libraries in comments or on twitter.


Source Code

GithubThe source code for this demo is available on GitHub.

Octopus Deploy in Your Cake (C# Make)

Octopus DeployI’ve looked at using Cake (C# Make) for build automation in C#.  The basics were to compile a solution/project using MSBuild and then run our automated tests with xUnit.

Another common set of tasks that are performed in a build pipeline are:

  • Create a NuGet package
  • Push the NuGet package to Octopus Deploy
  • Create an Octopus Deploy Release

NuGet

First thing we need to do is to create a NuGet package.  You have a couple options here, one is to create a nuspec and invoke the Nuget.exe to create your package.  I’m going to choose an alternative which is to use the built-in Nuget support to generate our NuGet package all within code.

I’ve added a new “Pack” task which is called from our “Default” task.  This task will create our NuGet package when we run our build.ps1

Now when we run our build, we can see the Pack task was created our NuGet package: “CakeDemo.0.0.0.1.nupkg”

pack

Octopus Deploy

Cake has built-in support for Octopus Deploy.  To get started, you need to include the OctopusTools in your build.cake file.

#tool "nuget:?package=OctopusTools"

We can use the OctoPush method for pushing your newly created NuGet package to the Octopus Deploy NuGet Server.

Create Release

Now that our NuGet package has been pushed to Octopus Deploy, we can create a release using the OctoCreateRelease method.

To tie this all together, we need to make sure that our Default task will run our OctoPush and OctoRelease tasks.  Here is our final build.cake file

Now when we run our build we can see that our Octopus Deploy release was created.

result

More

There are a ton of built-in tasks and the Cake documentation is really good.  Hopefully you can see the benefits of having a build script in code which can be version controlled and run anywhere.

Let me know if you have any comments related to Cake or any other build automation tooling either in comments or on twitter.


Source Code

GithubThe source code for this demo is available on GitHub.

Automating Builds with Cake (C# Make)

Cake C# MakeI’ve used various build systems for compiling, testing and deploying .NET based applications.

TFS, VSTS, AppVeyor, TeamCity have had one thing in common.

They all contained the configuration of my build, test and deploy pipeline in their system with no way to extract it.

Build as Code

Removing the build steps out of your build system and turning into code has two major benefits to me:

  1. Build Anywhere: Once you have a build script, you should be able to execute and build it anywhere.  No longer are you relying on the build server and it’s build steps which are specific to that build system.
  2. Source Control: Since you build is now in code, can can live right along side your application in source control.  This means that if you have the source, you have the build script.

Cake?

Cake (C# Make) is a build automation tool for .NET.  It allows you to write C# to run various Tasks that you would likely find as build steps on your build server.  Such as compile code (msbuild), run unit tests (xunit, nunit, mstests), creating nuget packages, create deployments via Octopus Deploy and a pile more.

Getting Started

It’s really easy to get started using Cake.  I’ve created a demo which is available on GitHub.  It contains a basic Hello World application along side the Cake script described in the rest of this blog.

Video

If you prefer watching a video tutorial, I’ve added a video that outlines the same content as this blog.

Build Script

First thing you need to do is get the Cake build script that is written in PowerShell.  From your project folder, run the following command to download the latest PowerShell Ssript (build.ps1)

Invoke-WebRequest http://cakebuild.net/download/bootstrapper/windows -OutFile build.ps1

Cake Script

Next we need to create our Cake script.  This script will define all the build tasks that the PowerShell Build Script (build.ps1) will execute.

Create an empty file “build.cake” in the same directory along side the build.ps1.

I recommend using VS Code along with the Cake extension to create and edit your build.cake file.

Build

In this my demo application, I have a CakeDemo.sln that I’m going to build.  it contains two projects, CakeDemo and CakeDemo.Tests which has an xUnit test.

solution

 

In our build.cake, let’s setup our first task to run MSBuild on our solution.

Above we define a task named “Default” which calls MSBuild.  Then to invoke Cake by calling RunTarget specifying our default task.

Now we can run our build.ps1 powershell script which will execute our build.cake C# script.

output

You can see that Cake downloaded some packages from NuGet which it requires to run the build, compiled our build.cake, and then executed it and its tasks (MSBuild).

If we take a look in our bin\ directory, we can see all the build output files.

C# Make

Running Tests

There are many different types of tasks you can define in your cake script.  Take a look at all the built-in API’s.

A common task you may perform is running Unit Tests.  In my Demo I have a project with an xUnit test.

We can run the xunit console test running from our cake script as well.

The fist thing we do is tell Cake we need an external tool from NuGet. In our case we need the xunit console runner.  At the top of our build.cake script, add

#tool "nuget:?package=xunit.runner.console"

Now we can add a task to run our xunit tests.

I’m going to modify our script a bit further in order to separate our compiling using msbuild and running our xunit tests into separate tasks.  You can tell Cake which tasks are depend on on others.

In this example, our xUnit task is going to be dependent on a build.

Let’s execute our build script again and see the output of our build and the xUnit console runner.

xunit

Integration

Now that we have our build in source code instead it being defined as build steps on our build server, we can simply invoke our build.ps1 from our build server as a single step.

More

There are a ton of built-in tasks and the Cake documentation is really good.  Hopefully you can see the benefits of having a build script in code which can be version controlled and run anywhere.

Let me know if you have any comments related to Cake or any other build automation tooling either in comments or on twitter.


Source Code

GithubThe source code for this demo is available on GitHub.