I started paying attention to gRPC about a year ago. Almost every gRPC advocate and evangelist I came across touted its performance capabilities as a significant value-add over other available service technologies.

The release of .NET Core 3.0 came with a new gRPC project template so I dove right in. During my explorations I found myself continually wondering how its performance stacked up against other service types available in .NET. A couple months ago I decided to circle back and satisfy this curiosity.

Methodology

After some consideration I decided to quantify performance characteristics for gPRC, Web API and WCF service implementations built with the latest (2020) .NET technologies. The best way to compare these services would have been to implement each targeting the same version of .NET (Core 3.1). Unfortunately, WCF has never been a well supported technology in .NET Core. Because of this I chose to create the WCF service implementation in .NET Framework 4.8. To help normalize service comparisons I decided to create separate .NET Core and Framework Web API implementations.

In order to compare services I defined a set of operations to be exposed by each and consumed by a common client. Completion times for each of these operations across all implementations could then be analyzed. Operations selected were as follows.

• Get - Get a fixed collection of objects from the service
• First - Get a single object from the service (the first in the fixed collection)
• Send - Send a fixed collection of objects to the service
• Send One - Send a single object to the service

Additionally, I decided to examine streaming operations available only with gRPC.

• Get Streaming - Stream a fixed collection of objects from a service
• Send Streaming - Stream a fixed collection of objects to a service

Setup

I started by creating a the service-compare branch of my Stupid Todo exploratory application. I added projects as needed for a total of four service implementations and a single client.

• StupidTodo.Grpc - gRPC service project, .NET Core 3.1
• StupidTodo.WebApi - ASP.NET Web API project, .NET Core 3.1
• StupidTodo.Framework.WebApi - ASP.NET Web API project, .NET Framework 4.8
• StupidTodo.Framework.Wcf - ASP.NET WCF project, .NET Framework 4.8
• StupidTodo.AdminConsole - Console application project used to gather data from each service implementation, .NET Core 3.1

Each service implementation exposes the previously discussed operations and shares the data provider GenFuDataProvider. That provider statically loads 5000 pre-generated Todo objects from a source shared by all implementations.

Each data set was gathered using an instance of the client backed by an instance of a specific service implementation. Both service and client instances were hosted side-by-side on the same physical machine.

Each data gathering cycle began in the client with a warm-up calling each available operation once. Afterwards, operations were executed one at time in the following order 1000 times each.

• Get
• Send
• First
• Send One
• Get Streaming (gRPC only)
• Send Steaming (gRPC only)

Execution times for each operation were recorded in the client.

During my initial research into gRPC performance I came across the blog post REST vs gRPC | Why Milliseconds Matter. In it the author (unnamed) found that the performance difference between gRPC and REST technologies became even more pronounced as the number of clients accessing the services increased. After reading this I decided to perform additional test runs where each set of operations was run on ten separate client instances simultaneously.

Results

Analysis

If we first compare the two primary technologies .NET Core and .NET Framework we find that .NET Core based services generally showed better performance. There were anomalies to this trend in the First and SendOne operations but I think these can be attributed to the extremely short response times. For those operations the uncertainty in measurements was large and thus the accuracy and utility of the data is questionable.

The results of the Get operation were largely as expected. gRPC performed the best followed by .NET Core Web API, then .NET Framework Web API and finally WCF. Additionally, these trends held for both the single client and ten simultaneous clients cases. The outlier was gRPC's service streaming. This operation was considerably slower than other Get variants and service streaming to ten simultaneous clients was especially slow. This is consistent with the fact that gRPC server streaming isn't designed as a high-performance data transfer mechanism. It's primary value proposition can be thought of as providing a long lived connection to a client.

The results of the Send operations were somewhat surprising. Here performance rankings were gRPC, .NET Core Web API, WCF and then .NET Framework Web API. The .NET Core based services behaved as might be expected but the fact that the WCF service outperformed the .NET Framework Web API is fairly shocking. I have no good explanation for the data but I replicated the experiment several times and consistently found similar results. Also, note that data for gRPC client streaming was absent. During testing upwards of 10% of gRPC Send attempts using client streaming resulted in some form of exception so these results were omitted. The common case found the server reporting that the connection had been closed before the client had completed sending all data.

Results from the First operations were again consistent with expectations showing service order by performance was gRPC, .NET Core Web API, .NET Framework Web API and WCF. Note how significant the variance is for the ten simultaneous clients tests in all cases. One interesting feature is that the WCF service shows very small performance differences between the single and ten simultaneous client cases. More testing would be needed here but results would seem to indicate that WCF handles increasing numbers of client connections quite efficiently for small get operations.

Results of the SendOne operations showed a number of unexpected results. Performance rankings were gRPC, WCF, .NET Core Web API and finally .NET Framework Web API. At first glance it seems very strange that WCF would out perform not only .NET Framework Web API (which was also the case in the Send operation) but also .NET Core Web API. However, examination of the deviation shows the variance in the WCF data to be on the order of the mean values. This is a clear indicator that the mean values alone do not give an accurate picture of results. An additional oddity is that the ten simultaneous WCF clients case showed better performance than the single client case. Here again note the significant variance especially in the single client data. If we refrain from drawing conclusions about the WCF data in this operation the remaining data shows trends consistent with expectations.

Conclusions

Through all testing gRPC performance was found to be superior to that of the other examined technologies. Most of the results confirmed the expectations that performance ranking would be gRPC, .NET Core Web API, .NET Framework Web API and finally WCF. The WCF data did exhibit a few unexpected and interesting results but nothing which convinced me that it wasn't the least performant overall.

Despite it's impressive performance gRPC in .NET Core (Grpc.Net) does have some limitations.

First, due to its heavy reliance upon HTTP/2 it is currently (2020) unsuitable as a service layer for most browser based applications. This limitation can be largely mitigated by the use of gRPC-Web but this project is currently "experimental". Though I haven't tested it yet, I suspect there's also a performance cost associated with its use.

To me the most significant limitation of Grpc.Net is that it's entirely reliant upon code generation based on your protobuf (Protocol Buffer) service definitions. Generated code is almost never sufficient as a domain model so you'll likely need to create and maintain a mapping layer between you domain model and the models generated by Grpc.Net. Such mapping code is often significant in size and can be brittle. The project protobuf-net.Grpc attempts to address this issue by allowing you to generate protobuf definitions from C#. It relies upon the use of data annotations in the C# code and supports both its own data annotations and many of those found in the System.ComponentModel.DataAnnotations namespace (same annotations used in WCF). I'd like to test the performance of this framework but my early explorations have been somewhat less than fruitful.

Grpc.Net definitely has potential. Today its use cases often involve service-to-service communication such as you might find in a micro-services architecture. For such cases the superior performance can be of significant benefit. Over time I expect the technology to continue improving and its use cases to broaden. I'll be watching with interest.

References

• Source Code - The service-compare branch of my Stupid Todo repository
• GenFu - Library used "to generate realistic test data" used in testing
• Compare gRPC services with HTTP APIs - Microsoft Docs article by James Newton-King
• Evaluating Performance of REST vs. gRPC - Blog post by Ruwan Fernando
• REST vs gRPC | Why Milliseconds Matter - Blog post by unnamed author
• Performance benchmark: gRPC vs. REST in .NET Core 3 Preview 8 - Blog post by Thang Chung
• protobuf-net - "Simple gRPC access in .NET Core 3 - think WCF, but over gRPC"

I've been working with Blazor Client (WASM) a fair amount recently and a couple of days ago someone asked me about how to load configuration from a file. I'd never had the need for that type of configuration before but it got me curious about what was possible.

After a little searching I discovered that configuration for Blazor WASM is typically being loaded through an HTTP GET request to a remote resource. That's a completely valid and viable solution but I was specifically curious about loading configuration directly from a file in the Blazor client project, e.g. appsettings.json.

Goal

Load a json configuration file directly from a Blazor WASM client using typical .NET Core practices for working with configuration.

Project Setup

I started by creating the Blazor WebAssembly App BlazorWasmConfig using the template in Visual Studio 2019 (note: I'd previously installed all required dependencies as documented in Getting started in ASP.NET Core Blazor). Next, I removed everything from the BlazorWasmConfig project I wouldn't need. This left me with the single page Index.razor which I'd use to display an object loaded from configuration.

My starting point.

I added the file appsettings.json.

{
  "GalaxyStuff": {
    "GalaxyCluster": "Virgo Supercluster",
    "GalaxyName": "Milky Way",
    "StarCount": 300000000000
  }
}

I defined the class GalaxyInfo to map configuration.

public class GalaxyInfo  
{
    public string GalaxyCluster { get; set; }
    public string GalaxyName { get; set; }
    public long StarCount { get; set; }

    public override string ToString()
    {
        return $"Galaxy: {GalaxyName}, Cluster: {GalaxyCluster}, Stars: {StarCount}";
    }
}

Finally, I installed two NuGet packages for configuration.

Install-Package Microsoft.Extensions.Configuration.Binder  
Install-Package Microsoft.Extensions.Configuration.Json  

Implementation

Creation of a configuration object in a .NET Core application typically looks something like this.

var config = new ConfigurationBuilder()  
                .SetBasePath(Directory.GetCurrentDirectory())
                .AddJsonFile("appsettings.json")
                .Build();

This tells the runtime to look for the file appsettings.json in the current directory and use it as a source for configuration. This simple pattern works well in .NET Core applications everywhere but utterly breaks down in Blazor WASM. The previous code compiles and executes without exceptions but when running in the browser Directory.GetCurrentDirectory() simply returns "/" and there are no files. No matter how you include appsettings.json in the Blazor client project the above method will never find it. This type of file IO simply does not apply to life in the browser.

The secret sauce to reading from a file included in the Blazor client project is including that file as an Embedded resource. This can be done in Visual Studio by setting the Build Action property of the file to Embedded resource and by setting the Copy to Output Directory property to Copy always (or Copy if newer). Alternately, you can specify both settings directly in the project file itself.

<ItemGroup>  
    <EmbeddedResource Include="appsettings.json">
        <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </EmbeddedResource>
</ItemGroup>

Once this is done you can read the file's contents as a Stream. The extension method AddJsonStream makes it easy to add this steam read to the configuration pipeline.

string fileName = "BlazorWasmConfig.appsettings.json";  
var stream = Assembly.GetExecutingAssembly()  
                     .GetManifestResourceStream(fileName)

var config = new ConfigurationBuilder()  
                    .AddJsonStream(stream)
                    .Build();

Note that this method is almost identical to the previous except that instead of loading appsettings.json from a on-disk file using AddJsonFile we are loading it through a stream from the embedded resource using AddJsonStream.

Using the previously defined config object we can then inject configuration into application components as needed. Illustrated here is a Singleton instance of the GalaxyInfo class initialized with data from configuration.

builder.Services.AddTransient(_ =>  
{ 
    return config.GetSection("GalaxyStuff")
                 .Get<GalaxyInfo>(); 
});

In Index.razor page we receive an instance of GalaxyInfo through the dependency injection pipeline shown above and display the ToString() of that object.

@page "/"
@inject GalaxyInfo GalaxyInfo

<h4>@nameof(GalaxyInfo) loaded as config from appsettings.json embedded resource</h4>  
@GalaxyInfo?.ToString()

Results

Conclusions

I was fairly surprised how easy this was to implement. I'm not sure I see a strong need for including a specific configuration file in a Blazor client (or any other web client) but considering how smoothly it went I'll definitely put that in my tool bag.

References

• BlazorWasmConfig - Source code
• Getting started in ASP.NET Core Blazor

Last year I saw a reference to LiteDB on Awesome .NET. It described itself as "An embedded NoSQL database for .NET". That drew my attention. A short examination of their documents further peaked my interest.

LiteDB describes its target scenarios in the Where to use section of the GitHub repo's readme.

• Desktop/local small applications
• Application file format
• Small web applications
• One database per account/user data store
• Few concurrent write operations

LiteDB will almost always be an inappropriate choice for persistence needs outside of these targets but within them it can be a simple to implement and effective solution.

For my exploration I created the litedb branch of the Stupid Todo reference application. In this branch I replaced the static data provider used in the master branch version of StupidTodo.WebApi.TodoController with a LiteDB implementation. Code examples shown here are snippets from that branch.

Using LiteDB

To get started with LiteDB just include the NuGet package. Note that the only dependencies are .NET 4.5 or .NET Standard 2.0 so it's compatible with the vast majority of .NET and .NET Core projects.

Install-Package LiteDB  

Most interactions with LiteDB will begin with an instance of LiteDatabase. Shown is the simplest where LiteDB looks for a file named stupid-todo.db in the execution directory and creates a new one (< 10 kb) if the file is not found.

using (var database = new LiteDatabase("stupid-todo.db"))  
{ ... }

CRUD operations with LiteDB are equally simple. Notice how GetCollection joins a specific .NET Type with a named collection in the database, i.e. the Todo Type joined to the todos collection. The resulting LiteCollection is then used to perform operations.

LiteCollection<Todo> todos = database.GetCollection<Todo>("todos");

// Get all Todo as an array
Todo[] allTodos = todos.FindAll().ToArray();

// Insert or update a Todo
bool upsertResult = todos.Upsert(todo);

// Delete Todo
bool deleteResult = todos.Delete(id);

Illustrated here are LiteCollection instance methods FindAll, Upsert and Delete but there are many others including Find, Insert, Update and Exists each with overloads.

LiteDB also supports a simple indexing mechanism. Call an overload of EnsureIndex after insert/update/upsert and the index will be added if it doesn't exist (Id fields are automatically indexed).

// Ensure a unique index on the Todo's Description field
todos.EnsureIndex(t => t.Description, true);  

Summary

LiteDB shows a focus on simplicity throughout. Its API is limited but sufficient for its target use cases. It's clearly not the right persistence solution for most scenarios but in its target range it works quite well.

References

• LiteDB - LiteDB Home
• LiteDB GitHub - LiteDB GitHub repository
• Source Code - litedb branch of StupidTodo on GitHub
• Stupid Todo - StupidTodo reference application on GitHub
• Stupid Todo / LiteDB Demo - Live demo of Stupid Todo using LiteDB persistence
• Awesome .NET - Blog aggregator that alerted me to LiteDB

My first exposure to Blazor was prior to it having a name. In late 2017 I watched a recording of Steve Sanderson's NDC Oslo 2017 presentation Web Apps can’t really do that, can they? He discussed four emerging web technologies being supported by the major browser manufacturers. One of those technologies was Web Assembly (WASM). In Steve's WASM demo he explored using ASP.NET Razor technology directly in the browser by compiling C# to Web Assembly using and open-source C# to C++ compiler. It was quite impressive and people's head's exploded, mine included. Shortly afterwards I discovered that Microsoft had initiated the experimental project "Blazor". Since then there's been a dearth of excitement. I finally decided to pull down bits and give Blazor as spin. For me that excitement became infectious.

Getting Started

Blog posts and code snippets are plentiful for installing and setting up Blazor. The official Get Started page covers the basics so I won't duplicate that here. A note to Windows users who routinely make use of both Visual Studio (VS) and the dotnet CLI, be sure to install the latest packages for both. You'd think that the VS install would subsume the dotnet CLI but in my experience that has not been the case.

After you have the Blazor SDK installed you'll find new Blazor templates in both VS (new project Web -> ASP.NET Core Web Application) and the dotnet CLI (dotnet new). Newly available project types are:

• Blazor (hosted in ASP.NET server) - ASP.NET project which provides a Web API to a dependent Blazor client application.
• Blazor Library - .NET Standard library project which aids in interfacing with JavaScript components.
• Blazor (Server-side in ASP.NET Core) - ASP.NET project which hosts both service and client applications providing real-time client-side HTML to the browser using SignalR.
• Blazor (standalone) - .NET Standard project which produces only the client-side Blazor, i.e. WASM.

In this exploration of Blazor I utilized the Blazor (standalone) project template to create a browser client which had feature parity with my Vue.js Stupid Todo client project. The result is the Blazor Stupid Todo client project project.

Coding with Blazor

Anyone familiar with ASP.NET Razor syntax will feel relatively at home working with Blazor. I've heard Daniel Roth say "Blazor is Razor in the browser" and that's essentially correct. The syntax used is almost identical but with Blazor page rendering occurs directly in the browser. This eliminates the need for a round-trip to the server for such rendering. With Blazor it's become a possibility that .NET developers will soon be able to build browser applications rivaling those created with JavaScript frameworks such as Angular and React.

At this point development patterns for Blazor are in their infancy and Microsoft's best (only) sample application is Flight Finder. Flight Finder makes use of a singleton instance of the class AppState to handle various application concerns. To me their use of the AppState class is reminiscent of a ViewModel in the Model/View/ViewModel (MVVM) pattern. The MVVM pattern has historically been applied to XAML frameworks (WPF, Xamarin, Silverlight) but to me it seems like it may be a reasonable fit with Blazor as well. I decided to explore this idea further.

A partial (and simplified) implementation of the MVVM pattern in Blazor applied to the Stupid Todo application has a Model (Todo.cs), View (Todo.cshtml) and ViewModel (TodoViewModel.cs).

Todo.cs (Model)

public class Todo  
{
    public string Description { get; set; }
    public bool Done { get; set; }
    public Guid Id { get; set; }
}

Todo.cshtml (View)

@inject TodoViewModel ViewModel

<div>  
    <button onclick=@(async () => await ViewModel.CheckDoneAsync())>Complete</i></button>
    <input type="text" bind=@ViewModel.Todo.Description />
    <button onclick=@(async () => await ViewModel.SaveAsync())>Save</button>
</div>

@functions
{
    [Parameter]
    private Todo SourceTodo { get; set; }

    protected override void OnInit()
    {
        ViewModel.Load(SourceTodo);
    }
}

TodoViewModel.cs (ViewModel)

public class TodoViewModel  
{    
    public TodoViewModel(HttpClient httpClient)
    {
        HttpClient = httpClient;
    }

    public async Task CheckDoneAsync()
    {
        Todo.Done = true;
        await SaveAsync();
    }

    public void Load(Todo todo)
    {
        Todo = todo;
    }

    public async Task SaveAsync()
    {
        var response = await HttpClient.PutAsync($"https://stupidtodo-api.azurewebsites.net/api/{Todo.Id}, Todo);
    }

    public Todo Todo { get; set; }  
    private readonly HttpClient HttpClient;
}

In the ConfigureServices method of Startup.cs we wire up the needed dependencies.

services.AddSingleton<TodoViewModel>()  
        .AddSingleton<HttpClient>(new HttpClient());

The Todo component can then be leveraged in parent component as a simple element in the .cshtml.

<Todo SourceTodo="@SelectedTodo" />  

In this way the parent component can create a rendered Todo (Model) by passing an instance of a Todo to the child component as a Parameter. The OnInit of method of the child View component calls the ViewModel's Load method passing it the View's Parameter Todo. All bindings in the View reference the ViewModel and everything just works. Excellent!

One caveat, two-way bindings in Blazor work fairly well even now but binding updates for inputs fire on leave of the input, not on its change. Steve Sanderson has said the solution will be to utilize bind-value-oninput instead of bind in the .cshtml but as of 0.6.0 that path is non-functional.

Conclusions

As of this post Blazor is roughly a year old and the current latest version of is 0.6.0. Already there are dozens of excellent articles, blog posts and videos on the technology. Enthusiasm in the .NET community is very high and Blazor looks to have the momentum to move towards production. At the moment Blazor is as rough as you might expect a pre-release framework to be. You'll encounter missing features and nagging tooling issues with any significant development effort you undertake. That said, what Blazor has accomplished in its relatively short existence is extremely impressive. Since these explorations I've found myself pondering whether or not I'll ever voluntarily create a JavaScript client again. That's fairly ironic considering my last post Vue.js where I sing that framework's praises.

Future

Several years ago I posted How HTML5 destroyed my CSLA dream. For quite some time I've been contemplating a new post along the lines of "How Microsoft Rescued my CSLA dream". My plan had been to discuss how Xamarin and the future release of XMAL Standard could potentially restore my dream of writing end-to-end, multi-layered and multi-tiered applications using a single set of semantics (language). Until now I've been under the assumption that XAML would serve as the client-side markup in this new landscape. Blazor has me considering a whole new set of possibilities and I'm pretty excited about the potential.

References

• Blazor, Blazor home
• Stupid Todo Blazor, Blazor branch of the StupidTodo exploratory application's source code repository
• Web Apps can’t really do that, can they?, Steve Sanderson, NDC Oslo 2017, video
• CSLA running on Blazor, Rockford Lhotka, blog post
• Blazor: Modern Web development with .NET and WebAssembly, Daniel Roth, .NET Conf 2018, video
• Stupid Todo Client, Blazor, live instance of the Blazor Stupid Todo client
• Stupid Todo Client, Vue.js, live instance of the Vue.js Stupid Todo client

Several months ago I found myself contemplating the creation of yet another HTML client, this time to help in prototyping a larger application concept I was working on. I wanted the client to be responsive and I didn't want to put a lot of work into it.

There's a wide variety of excellent frameworks to choose from when building HTML clients. Frameworks such as Angular, React and Aruelia offer rich feature sets for building amazing web applications but all of them come at a cost, e.g. npm, web pack, development web servers, etc. I wanted something simpler.

In searching for simple HTML client application frameworks I quickly encountered Vue.js. It was exactly what I was looking for. Vue requires only a single .js file reference for the base framework.

<script src="{path}/vue.js"></script>  

The addition of a second file is needed for interactions with HTTP services.

<script src="{path}/vue-resource.js"></script>  

With these two references in place, the ubiquitous Bootstrap and application specific app.js and index.html files an impressively full-featured client application can be created with a few dozen lines of code.

Vue can be used to create large-scale, componentized client applications rivaling anything you might see in other frameworks but it also allows for ultra-rapid creation of basic HTML client applications. In this Vue excels above most of its rivals.

I used Vue to create an simple HTML client for my Stupid Todo exploratory application (live demo). For that application the combined line count of the app.js and the index.html files is ~180. It's a fairly impressive illustration of what can be accomplished using Vue with only 180 lines of written code.

I created a short video discussing Vue and demonstrating the Vue client for Stupid Todo.

If you're like me and occasionally have the need to create simple HTML client applications I recommend you give Vue.js a look.

References

• Vue.js, Vue.js home
• Stupid Todo, GitHub repo
• Stupid Todo Vue, live Vue client for the Stupid Todo exploratory application (allow time to warm-up the free-tier Azure Web App)
• Vue.js with TypeScript, blog entry by John Papa

I'm primarily a .NET developer but for a year I worked exclusively on a MacBook using Boot Camp to run Windows 10.

Like many software companies the one I work for provides its development staff with options for their working computers. My options were a MacBook Pro or a Dell. I'd used three different Dell laptops in my career and I disliked every one of them so I went with the MacBook. I've used OSX in the past and I despised it. I had no interest in using it as my primary OS so I ran Windows 10 on the MacBook hardware using Apple's excellent Boot Camp. Here's the pros and cons I encountered after a year of dedicated use with a MacBook running Windows.

Pros

• Physically solid. The MacBook just feels well constructed. Every aspect of it's design indicates precision and quality.
• Amazing screen quality. The MacBook has a Retina Display screen. Its screen quality is well beyond anything I've ever experienced with a laptop.
• Good hardware resources. Intel i7 (4 core), 16 GB RAM and 1 TB SSD
• Attention to detail. Apple's design details are top notch. The MackBook has many elegant and functional features, e.g. the small bevel on the top edge of the screen frame which allows the user to easily open a closed laptop.

Cons

• Hardware virtualization issues. The process of getting hardware virtualization working with Boot Camp Windows 10 is painful. Unfortunately, hardware vitalization is required to run Docker for Windows. This impedance to running Docker is what finally drove me to give up the MacBook.
• Touchpad too "grab" happy. I routinely grabbed files/folders I'd only meant to select. This caused me many headaches with accidentally moved files.
• Screen maring. I cleaned my screen with desalinated water and a micro-fiber cloth and still it was permanently marred. I discovered this is not an uncommon issue with the model of MacBook I had.
• Power button placement. The MacBook power button is simply the top-right button on the keyboard. Every laptop I'd ever used had a power button that was separate from the keyboard proper. I can't count the number of times I meant to hit delete and instead shut down my machine. It still occasionally happened after a full year.
• Battery life was not good. When new I'd get ~4 hours of battery life while coding. That dropped over the year to less than 3 hours.
• Remote desktop issues run amok. RDP always had DPI issues and connection issues requiring reboot to solve.

I enjoyed much about the MacBook in the year I used it. I think Apple did a fairly tremendous job with Boot Camp and if I'd had a more reliable experience with Docker this post might be something very different. In the end I always felt a little like I was paddling upstream trying to run Windows on a MacBook. I guess that's not really a surprising conclusion. Perhaps someday Boot Camp will provide a more complete experience for Windows on a MacBook. For now...I've accepted a Dell as my primary work computer. For me that about says it all.

My first look into F# was in 2011 when I read Programming F#. I enjoyed working through that book and I realized that F# had opened the door to functional programming in .NET but at the time C# was vastly superior in both available information and developer experience. I set F# aside.

Recently I helped interview candidates applying for a principal software engineering position. One candidate (now employee) was very enthusiastic about functional programming in general and F# in particular. His enthusiasm rekindled my interest.

I started looking into the current state of F# and quickly discovered the previously mentioned gaps had closed significantly. Microsoft has made a commitment to F# as a first-class language and its projects are now beautifully interopable with the majority of other .NET project types. I decided I needed to re-explore F#.

F# Exploration Project

For my second dive into F# I decided to use Giraffe to recreate a web API I'd previously written in C#. Giraffe describes itself as "A native functional ASP.NET Core web framework for F# developers." My TrackIt exploratory application includes the ASP.NET Core Web API C# project TrackIt.Services.CoreWebApi. I used that project as the feature parity target for a new F# project. TrackIt.Services.GiraffeWebApi is the result.

Project Comparison

When complete the Giraffe implementation was a feature match for the one I'd previously created in C#. The following gives a sense of the differences in C# and F# code showing in-code handling of an HTTP DELETE to /datapoints/{id}

C#

public async Task<IActionResult> DeleteDataPointAsync(string id)  
{
    var result = await Manager.DeleteAsync(id);
    if (result.Success) { return Ok(result.Value); }
    else { return BadRequest(result); }
}

F#

let deleteDataPoint id =  
    fun (next : HttpFunc) (ctx : HttpContext) ->
        task {
            use manager = getDataPointManager configuration
            let! result = manager.DeleteAsync(id)
            if (result.Success) then return! jsonCamelCase true next ctx
            else return! (setStatusCode 400 >=> jsonCamelCase result) next ctx
        }

When I was done with the Griaffe project realized I had the opportunity to quantitatively compare feature parity code from two different languages. The metrics I decided upon for this comparison were file count, line count and significant character count.

Method

In each project only source code files were considered, i.e. .cs/.fs for the C#/F# projects respectively. Files were parsed for line count and significant characters. All blank lines and comments were excluded in parsing and significant character counts were found by trimming lines of spaces and removing tabs.

Results

Discussion

The Files metric shows 14% fewer files in the F# project. However, the difference is a single file. For the comparison sample size no significant conclusions should be drawn from this discrepancy.

The Lines metric shows 30% fewer lines in the F# project. That's a significant number largely explained by C#'s use of the curly brace coupled with my personal coding standards, i.e. C# curly braces get their own lines.

The Significant Characters metric shows 8% fewer significant characters in the F# project. This difference seems a bit underwhelming but I'd argue that 8% less total code in a large application is very significant.

Final Thoughts

During this process I've found myself again drawn to the terse and tightly constrained nature of the F# language. The support the language now enjoys, especially with .NET Core 2.0, opens the door to a staggering number possibilities. I can say with 100% confidence it won't be another 6 years before I find myself working in an F# project.

References

• TrackIt source code (GitHub project)
• Giraffe (GitHub project)
• Getting Started with ASP.NET Core Giraffe, Ody Mbegbu (Video)
• A Functional Web with ASP.NET Core and F#'s Giraffe, Scott Hanselman (Blog entry)
• My latest exploratory application, TrackIt, Developing Dane (Blog entry)

I first investigated Squirrel.Windows as a technology for Windows application deployment two years ago during a search for an alternative to ClickOnce (my 2 cents). I documented some of those efforts in my post ClickOnce, Squirrel and Nuts. In that post I expressed a very favorable opinion of Squirrel but I also I noted some areas of dissatisfaction in the discussion and conclusions.

• Latest version of the deployed application was not always run
• Cleanup of previous application versions wasn't working
• Instability with releasify command
• Reliance on historical .nupkg files from the Releases folder

Lately

Recently I again went in search of ClickOnce replacement options. It became quickly apparent not much had changed. Squirrel still looked to me to be the best available alternative so I took another dive. I examined the state of the issues previously discussed then developed a basic strategy for controlling Squirrel deployed releases.

Latest Version Issue

The first issue can now be resolved through the use of a simple static method on the class Squirrel.UpdateManager.

UpdateManager.RestartApp("{app_exe_name}");  

This works quite well and if added to an application's start-up, after a Squirrel update but before the rendering of the view, users will always be presented with the latest version of the application. Very nice.

Cleanup Issue

Application cleanup was still an issue when I started evaluating Squirrel the second time. In looking through GitHub issues for Squirrel.Windows I found others had the same problem so I attempted to debug it myself. I discovered that this issue was a trival defect. It's been since resolved. Squirrel now cleans older versions of the deployed application leaving only the current and one previous.

Releasify Instability Issue

This issue still exists, however, occurrences have GREATLY diminished. Previously the releasify command would stop working (requiring a Visual Studio restart) every 3-5 executions. During the second evaluation I encountered this issue exactly two times in roughly 100 executions.

Historical .nupkg Files Issue

In my first post I noted the releasify command relies on the output of the previous execution in order to generate delta packages. My concern was this would necessitate source control for binary .nupkg files. That would mean source control of binary files created by compiling code files stored in the same source control project. That's far from ideal.

Over the course of the second evaluation I developed a simple strategy to build and manage Squirrel deployment releases. This strategy addressed my concerns related to historical .nupkg files.

Squirrel Deployments Release Strategy

I developed the following strategy to provide controlled releases to Squirrel deployments. It assumes access to both a source control system and some form of shared file (binary) storage. Ideally both should be covered under some type of backup policy.

Setup and Initial Release

As described in Squirrel's Getting Started Guide the Squirrel.Windows NuGet package should installed in the start-up project of your Windows application.

In the static start-up of your application add code to check for available updates, apply any updates found and restart the application if updates were applied. All this should be performed prior to rendering the display. This ensures the user is always presented with the latest version of the application. The following code sample illustrates this method for a Windows Forms Application.

static class Program  
{
    [STAThread]
    static void Main()
    {
        Task.Run(() => CheckAndApplyUpdate()).GetAwaiter().GetResult();
        Application.EnableVisualStyles();       
        Application.SetCompatibleTextRenderingDefault(false);
        Application.Run(new Form1());
    }

    public static async Task CheckAndApplyUpdate()
    {
        bool updated = false;
        using (var updateManager = new UpdateManager(URI))
        {
            var updateInfo = await updateManager.CheckForUpdate();
            if (updateInfo.ReleasesToApply != null && 
                updateInfo.ReleasesToApply.Count > 0)
            {
                var releaseEntry = await updateManager.UpdateApp();
                updated = true;
            }
        }
        if (updated) { UpdateManager.RestartApp(EXE_NAME); }
    }

    private const string EXE_NAME = "WindowsFormsApp2.exe";
    private const string URI = "{URI to Releases folder}";
}

Add a {project}.nuspec file to the start-up project (be sure it's also added to source control). Include only file entries for the assemblies that are necessary to run the application through the Squirrel update and restart. Excluded all assemblies not required to get to that point. This ensures that the setup.exe file created by the initial releasify command will be as small as possible. Following is sample content for a .nuspec file's packages element. Note: The description element is required and its value is used by Windows search features to find the application.

<metadata>  
  <id>WindowsFormsApp2</id>
  <version>1.0.0</version>
  <authors>Dane Vinson</authors>
  <requireLicenseAcceptance>false</requireLicenseAcceptance>
  <description>WindowsFormsApp2</description>
</metadata>  
<files>  
  <file src=".\bin\Release\WindowsFormsApp2.exe" 
        target="lib\net45\WindowsFormsApp2.exe" />
  <file src=".\bin\Release\WindowsFormsApp2.exe.config" 
        target="lib\net45\WindowsFormsApp2.exe.config" />
  <file src=".\bin\Release\DeltaCompressionDotNet.dll" 
        target="lib\net45\DeltaCompressionDotNet.dll" />
  <file src=".\bin\Release\DeltaCompressionDotNet.MsDelta.dll" 
        target="lib\net45\DeltaCompressionDotNet.MsDelta.dll" />
  <file src=".\bin\Release\DeltaCompressionDotNet.PatchApi.dll" 
        target="lib\net45\DeltaCompressionDotNet.PatchApi.dll" />
  <file src=".\bin\Release\Mono.Cecil.dll" 
        target="lib\net45\Mono.Cecil.dll" />
  <file src=".\bin\Release\NuGet.Squirrel.dll" 
        target="lib\net45\NuGet.Squirrel.dll" />
  <file src=".\bin\Release\SharpCompress.dll" 
        target="lib\net45\SharpCompress.dll" />
  <file src=".\bin\Release\Splat.dll" 
        target="lib\net45\Splat.dll" />
  <file src=".\bin\Releas\Squirrel.dll" 
        target="lib\net45\Squirrel.dll" />
</files>  

Create the initial release

1. Build the start-up project
2. Create .nupkg from .nuspec
3. releasify the .nupkg
4. Commit changes to .nuspec file

The initial "minified" setup.exe file should deployed to a location accessible to any potential application users. Designed correctly it's possible for this file to serve as the application's primary installer for its lifetime.

The first change to the application should be to add file entries to the .nuspec file for all remaining application dependencies. This should be considered a release. For this and all future releases proceed with the steps below.

Create New Release

Creation of Squirrel deployment releases should follow these steps.

1. Commit changes for the release
2. Delete Releases from the build-time environment (if it exists)
3. Copy Releases from the shared location to the build-time environment
4. Increment the version element in the .nuspec file
5. Build the start-up project
6. Create .nupkg from .nuspec
7. releasify the .nupkg
8. Commit changes to .nuspec
9. Copy newest *.nupkg and RELEASES files from build-time Releases folder to the shared Releases location

If for any reason the shared Releases repository is lost simply re-create an empty Releases folder at the share location and repeat the previous steps. The next time users run the application they'll have to download all files but the application will continue to function correctly. Even a fresh install with the original "minified" setup.exe will correctly update to the latest version of the application. I've found Squirrel to be quite resilient with respect to historical .nupkg files.

Conclusions...the Sequel

Once again I've been impressed with Squirrel. As an application updater it's matched or surpassed ClickOnce in almost every way. The one remaining feature of ClickOnce that Squirrel does not provide is the ability to run the application directly from a browser. I didn't discuss this in my previous post because I felt it fell beyond Squirrel's intent. That said there are numerous benefits to that feature not the least of which is that it eliminates the need for an actual "installer" (e.g. setup.exe).

Finally

I'm currently working towards using Squirrel and the described release strategy to replace ClickOnce in of one of my company's production applications. I'm also working on an idea to provide install/run capabilities directly from the browser but as of now that's only partially formed.

I've found myself trying to quantify differences between available data store options in .NET many times over the last decade. Historically I've performed such comparisons using a simple Console Application project in Visual Studio. I'd write test methods to provide comparable data for the data stores under evaluation, analyze the data, select for implementation and move forward. I've experienced success with this pattern for many years.

Recently, I found myself about to write code for yet another such comparison, once again I was re-inventing some testing methodologies. This time I decided to create (and document) an abstraction layer around the concept of a data store. My thinking was to provide a single testable abstraction that could be implemented in any .NET data storage technology. Not only would future tests be easier to write but the empirical data they generated would be standardized and thus comparable.

Objective

Design an abstraction layer in .NET which defines the concept of a "data store" then implement this abstraction using an array of .NET data storage technologies. Gather data. Compare and contrast results.

Source Code

DataRepositoryComparison is a Visual Studio solution targeting .NET 4.6.1. It contains the projects Model (Class Library), ConsoleApp (Console Application) and multiple separate data store implementation projects, e.g. Sql.Dapper. The Model project defines the common domain model abstractions to be used by all concrete implementations. ConsoleApp provides a run-time environment for testing. All other projects are specific implementations of the Model project's abstractions using a particular .NET data store technology, e.g. Dapper.

The Repository pattern is employed and an abstraction of the "data store" concept is defined.

public interface IRepository  
{
    bool Create(IEnumerable<IThing> things);
    bool Delete(IEnumerable<string> ids);
    IThing[] Get();
    IThing[] Get(IEnumerable<string> ids);
}

This design allows for the creation of IThing entities, deletion of IThing entities by identifier, retrieval of all available IThing entities and retrieval of IThing entities by identifier. Note, IRepository has no metaphor for query (excluding by identifier) or update.

Setup

All testing was performed using the following Azure VM (Resource Manger deployment model).

• Template: SQL Server 2016 SP1 Standard on Windows Server 2016
• Size: DS2_V2 (2 Core, 7 GB, $104.16/month)
• Disk Type: SSD

The following IRepository implementations and their associated configurations were used to gather data.

• Sql.Dapper: Local (VM) SQL Server
• Sql.Dapper: Azure SQL, Basic (5 DTU), $5/month
• Sql.Dapper: Azure SQL, Premium (125 DTU), $465/month
• DocumentDB: 400 RU, $24/month/collection
• DocumentDB: 10,000 RU, $600/month/collection
• AzureStorageTable: Premium Account, LRS
• AzureStorageBlob: Premium Account, LRS

Method

The following is a simplified version of the data gathering cycle applied to each IRepository implementation.

IRepository repository = {concrete_implementation_instance};  
IThing[] things = {GenFu_IThing_data};  
repository.Create(things);  
ids = repository.Get().Select(t => t.Id).ToArray();  
repository.Get(ids);  
repository.Delete(ids);  

Timers were scoped around each IRepository method call and completion times were recorded.

For each IRepository implementation data was gathered using 100 iterations of the cycle each with 100 randomly generated IThing entities (thank you GenFu). Additionally, data gathering cycles were executed both synchronously and asynchronously.

Results

Discussion

The "LocalSql" repository shown in the charts (Sql.Dapper implementation of IRepository on VM local resources) serves as an excellent baseline for comparisons. As expected "local" repository times for all actions are faster than those of other repositories. Most are significantly faster.

In almost every case asynchronous operations outperformed their synchronous counterparts. However, for Sql.Dapper Azure SQL the differences were dramatic in operations executed with unique Id, i.e. Create, Get, Delete. Note that for the remaining operation, i.e. GetAll, synchronous actually slightly outperformed asynchronous. The data suggests that Azure SQL is heavily optimized for asynchronous operations. That's consistent with expectations.

Excluding synchronous operations Sql.Dapper on Azure SQL made a strong showing. Even the Azure Basic tier database performs near the top of every operation. Also noteworthy is the performance of AzureStorageTable, again near the top in performance for each operation. A surprise for me was AzureStorageBlob. This implementation literally just serializes each IThing to json and writes it to an individual file on Azure Blob Storage. That would seem to be a horribly inefficient way to store data but, with the exception of GetAll, the performance is admirable.

Conclusions

The abstraction IRepository worked well with implementations of a widely varied group of data storage technologies. Implementations were simple to write and data gathered from exercising them was easily comparable. I'm satisfied with the results and will likely add additional implementations in the future.

References

• DataRepositoryComparison (source code)
• Dapper
• DocumentDB
• Azure Storage Tables
• Azure Storage Blob

I had a need to understand the options for scheduling Azure WebJobs. I quickly found the Azure documentation article Run background tasks with WebJobs which provides two possible methods for scheduling the execution of a WebJob, CRON expression and the use of Azure Scheduler. Those options were a good start and I'd like to discuss my thoughts on them and present additional possibilities.

Option 1

For CRON expressions the article describes the use of a settings.job file. What's not clear in that article is where this file originates. It turns out its added to your WebJob when you create a Triggered, Scheduled WebJob through the Azure Portal.

Option 2

Use Visual Studio to manually add settings.job to a console app (be sure the file's Copy to output directory property is set to Copy always) and then deploy that app as a Run on Demand WebJob using VS publishing.

Option 3

The Azure WebJobs SDK provides yet another method of creating CRON driven WebJobs. This method utilizes the SDK's TimerTrigger and requires a Continous WebJob. The WebJob can be created using the Azure Portal or by VS publishing as long as it's Continuous.

TriggerTimer is an attribute applied to a method argument of type TimerInfo. Its constructor takes a CRON expression string. By convention this method is to be implemented in the Functions class of the console app to be deployed.

public class Functions  
{
    public static void MyJob([TimerTrigger("0 * * * * *")]TimerInfo timer)
    {
        // Do stuff
    }
}

Options 1-3 Restrictions

Each of the CRON expression methods previously described requires the Azure App Service hosting the WebJob be Always On. This means that the App Service's scaling tier must be Basic (currently $55/month) or higher. For many user's legitimate WebJob use cases the cost/benefit ratio simply doesn't make sense at that monthly cost.

Option 4

Users who require a cheaper solution will likely need to employ the second option from the originally referenced article, i.e. using Azure Scheduler to trigger Azure WebJobs. In that scenario there's no restriction on App Service pricing tier, i.e. Free works, and the cost for Azure Scheduler is minimal. The downside is, of course, an increase in system complexity.

References

• Run background tasks with WebJobs
• Azure WebJobs SDK Github
• Scheduling Azure WebJobs with cron expressions
• Deploying and Schedule Azure WebJobs from VSTS to Azure Web App (With bonus CRON Scheduling)