Accelerated 3D VR, sure, but impress me with a nice ASCII progress bar or spinner

I’m glad you have a 1080p 60fps accelerated graphics setup, but I’m told school. Impress me with a really nice polished ASCII progress bar or spinner! I received two tips this week about cool .NET Core ready progress bars so I thought I’d try them out….

I'm glad you have a 1080p 60fps accelerated graphics setup, but I'm told school. Impress me with a really nice polished ASCII progress bar or spinner!

I received two tips this week about cool .NET Core ready progress bars so I thought I'd try them out.

ShellProgressBar by Martijn Laarman

This one is super cool. It even supports child progress bars for async stuff happening in parallel! It's very easy to use. I was able to get a nice looking progress bar going in minutes.

static void Main(string[] args)

{
const int totalTicks = 100;
var options = new ProgressBarOptions
{
ForegroundColor = ConsoleColor.Yellow,
ForegroundColorDone = ConsoleColor.DarkGreen,
BackgroundColor = ConsoleColor.DarkGray,
BackgroundCharacter = '\u2593'
};
using (var pbar = new ProgressBar(totalTicks, "Initial message", options))
{
pbar.Tick(); //will advance pbar to 1 out of 10.
//we can also advance and update the progressbar text
pbar.Tick("Step 2 of 10");
TickToCompletion(pbar, totalTicks, sleep: 50);
}
}

Boom.

Cool ASCII Progress Bars in .NET Core

Be sure to check out the examples for ShellProgressBar, specifically ExampleBase.cs where he has some helper stuff like TickToCompletion() that isn't initially obvious.

Kurukuru by Mayuki Sawatari

Another nice progress system that is in active development for .NET Core (like super active...I can see they updated code an hour ago!) is called Kurukuru. This code is less about progress bars and more about spinners. It's smart about Unicode vs. non-Unicode as there's a lot of cool characters you could use in a Unicode-aware console that make for attractive spinners.

What a lovely ASCII Spinner in .NET Core!

Kurukuru is also super easy to use and integrated into your code. It also uses the "using" disposable pattern in a clever way. Wrap your work and if you throw an exception, it will show a failed spinner.

Spinner.Start("Processing...", () =>

{
Thread.Sleep(1000 * 3);

// MEMO: If you want to show as failed, throw a exception here.
// throw new Exception("Something went wrong!");
});

Spinner.Start("Stage 1...", spinner =>
{
Thread.Sleep(1000 * 3);
spinner.Text = "Stage 2...";
Thread.Sleep(1000 * 3);
spinner.Fail("Something went wrong!");
});

TIP: If your .NET Core console app wants to use an async Main (like I did) and call Kurukuru's async methods, you'll want to indicate you want to use the latest C# 7.1 features by adding this to your project's *.csproj file:

<PropertyGroup>
    <LangVersion>latest</LangVersion>
</PropertyGroup>

This allowed me to do this:

public static async Task Main(string[] args)

{
Console.WriteLine("Hello World!");
await Spinner.StartAsync("Stage 1...", async spinner =>
{
await Task.Delay(1000 * 3);
spinner.Text = "Stage 2...";
await Task.Delay(1000 * 3);
spinner.Fail("Something went wrong!");
});
}

Did I miss some? I'm sure I did. What nice ASCII progress bars and spinners make YOU happy?


Sponsor: Check out JetBrains Rider: a new cross-platform .NET IDE. Edit, refactor, test and debug ASP.NET, .NET Framework, .NET Core, Xamarin or Unity applications. Learn more and download a 30-day trial!



© 2017 Scott Hanselman. All rights reserved.
     

Writing smarter cross-platform .NET Core apps with the API Analyzer and Windows Compatibility Pack

There’s a couple of great utilities that have come out in the last few weeks in the .NET Core world that you should be aware of. They are deeply useful when porting/writing cross-platform code. .NET API Analyzer First is the API Analyzer. As you know, …

.NET Core is Open Source and Cross PlatformThere's a couple of great utilities that have come out in the last few weeks in the .NET Core world that you should be aware of. They are deeply useful when porting/writing cross-platform code.

.NET API Analyzer

First is the API Analyzer. As you know, APIs sometimes get deprecated, or you'll use a method on Windows and find it doesn't work on Linux. The API Analyzer is a Roslyn (remember Roslyn is the name of the C#/.NET compiler) analyzer that's easily added to your project as a NuGet package. All you have to do is add it and you'll immediately start getting warnings and/or squiggles calling out APIs that might be a problem.

Check out this quick example. I'll make a quick console app, then add the analyzer. Note the version is current as of the time of this post. It'll change.

C:\supercrossplatapp> dotnet new console

C:\supercrossplatapp> dotnet add package Microsoft.DotNet.Analyzers.Compatibility --version 0.1.2-alpha

Then I'll use an API that only works on Windows. However, I still want my app to run everywhere.

static void Main(string[] args)

{
Console.WriteLine("Hello World!");

if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
{
var w = Console.WindowWidth;
Console.WriteLine($"Console Width is {w}");
}
}

Then I'll "dotnet build" (or run, which implies build) and I get a nice warning that one API doesn't work everywhere.

C:\supercrossplatapp> dotnet build


Program.cs(14,33): warning PC001: Console.WindowWidth isn't supported on Linux, MacOSX [C:\Users\scott\Desktop\supercr
ossplatapp\supercrossplatapp.csproj]
supercrossplatapp -> C:\supercrossplatapp\bin\Debug\netcoreapp2.0\supercrossplatapp.dll

Build succeeded.

Olia from the .NET Team did a great YouTube video where she shows off the API Analyzer and how it works. The code for the API Analyzer up here on GitHub. Please leave an issue if you find one!

Windows Compatibility Pack for .NET Core

Second, the Windows Compatibility Pack for .NET Core is a nice piece of tech. When .NET Core 2.0 come out and the .NET Standard 2.0 was finalized, it included over 32k APIs that made it extremely compatible with existing .NET Framework code. In fact, it's so compatible, I was able to easily take a 15 year old .NET app and port it over to .NET Core 2.0 without any trouble at all.

They have more than doubled the set of available APIs from 13k in .NET Standard 1.6 to 32k in .NET Standard 2.0.

.NET Standard 2.0 is cool because it's supported on the following platforms:

  • .NET Framework 4.6.1
  • .NET Core 2.0
  • Mono 5.4
  • Xamarin.iOS 10.14
  • Xamarin.Mac 3.8
  • Xamarin.Android 7.5

When you're porting code over to .NET Core that has lots of Windows-specific dependencies, you might find yourself bumping into APIs that aren't a part of .NET Standard 2.0. So, there's a new (preview) Microsoft.Windows.Compatibility NuGet package that "provides access to APIs that were previously available only for .NET Framework."

There will be two kinds of APIs in the Compatibility Pack. APIs that were a part of Windows originally but can work cross-platform, and APIs that will always be Windows only, because they are super OS-specific. APIs calls to the Windows Registry will always be Windows-specific, for example. But the System.DirectoryServices or System.Drawing APIs could be written in a way that works anywhere. The Windows Compatibility Pack adds over 20,000 more APIs, on top of what's already available in .NET Core. Check out the great video that Immo shot on the compat pack.

The point is, if the API that is blocking you from using .NET Core is now available in this compat pack, yay! But you should also know WHY you are pointing to .NET Core. Work continues on both .NET Core and .NET (Full) Framework on Windows. If your app works great today, there's no need to port unless you need a .NET Core specific feature. Here's a great list of rules of thumb from the docs:

Use .NET Core for your server application when:+

  • You have cross-platform needs.
  • You are targeting microservices.
  • You are using Docker containers.
  • You need high-performance and scalable systems.
  • You need side-by-side .NET versions per application.

Use .NET Framework for your server application when:

  • Your app currently uses .NET Framework (recommendation is to extend instead of migrating).
  • Your app uses third-party .NET libraries or NuGet packages not available for .NET Core.
  • Your app uses .NET technologies that aren't available for .NET Core.
  • Your app uses a platform that doesn’t support .NET Core.

Finally, it's worth pointing out a few other tools that can aid you in using the right APIs for the job.

Enjoy!


Sponsor: Get the latest JetBrains Rider preview for .NET Core 2.0 support, Value Tracking and Call Tracking, MSTest runner, new code inspections and refactorings, and the Parallel Stacks view in debugger.


© 2017 Scott Hanselman. All rights reserved.
     

Trying out new .NET Core Alpine Docker Images

I blogged recently about optimizing .NET and ASP.NET Docker files sizes. .NET Core 2.0 has previously been built on a Debian image but today there is preview image with .NET Core 2.1 nightlies using Alpine. You can read about the announcement here abou…

Docker ContainersI blogged recently about optimizing .NET and ASP.NET Docker files sizes. .NET Core 2.0 has previously been built on a Debian image but today there is preview image with .NET Core 2.1 nightlies using Alpine. You can read about the announcement here about this new Alpine preview image. There's also a good rollup post on .NET and Docker.

They have added two new images:

  • 2.1-runtime-alpine
  • 2.1-runtime-deps-alpine

Alpine support is part of the .NET Core 2.1 release. .NET Core 2.1 images are currently provided at the microsoft/dotnet-nightly repo, including the new Alpine images. .NET Core 2.1 images will be promoted to the microsoft/dotnet repo when released in 2018.

NOTE: The -runtime-deps- image contains the dependancies needed for a .NET Core application, but NOT the .NET Core runtime itself. This is the image you'd use if your app was a self-contained application that included a copy of the .NET Core runtime. This is apps published with -r [runtimeid]. Most folks will use the -runtime- image that included the full .NET Core runtime. To be clear:

- The runtime image contains the .NET Core runtime and is intended to run Framework-Dependent Deployed applications - see sample

- The runtime-deps image contains just the native dependencies needed by .NET Core and is intended to run Self-Contained Deployed applications - see sample

It's best with .NET Core to use multi-stage build files, so you have one container that builds your app and one that contains the results of that build. That way you don't end up shipping an image with a bunch of SDKs and compilers you don't need.

NOTE: Read this to learn more about image versions in Dockerfiles so you can pick the right tag and digest for your needs. Ideally you'll pick a docker file that rolls forward to include the latest servicing patches.

Given this docker file, we build with the SDK image, then publish, and the result is about 219megs.

FROM microsoft/dotnet:2.0-sdk as builder  


RUN mkdir -p /root/src/app/dockertest
WORKDIR /root/src/app/dockertest

COPY dockertest.csproj .
RUN dotnet restore ./dockertest.csproj

COPY . .
RUN dotnet publish -c release -o published

FROM microsoft/dotnet:2.0.0-runtime

WORKDIR /root/
COPY --from=builder /root/src/app/dockertest/published .
ENV ASPNETCORE_URLS=http://+:5000
EXPOSE 5000/tcp
CMD ["dotnet", "./dockertest.dll"]

Then I'll save this as Dockerfile.debian and build like this:

> docker build . -t shanselman/dockertestdeb:0.1 -f dockerfile.debian

With a standard ASP.NET app this image ends up being 219 megs.

Now I'll just change one line, and use the 2.1 alpine runtime

FROM microsoft/dotnet-nightly:2.1-runtime-alpine

And build like this:

> docker build . -t shanselman/dockertestalp:0.1 -f dockerfile.alpine

and compare the two:

> docker images | find /i "dockertest"

shanselman/dockertestalp 0.1 3f2595a6833d 16 minutes ago 82.8MB
shanselman/dockertestdeb 0.1 0d62455c4944 30 minutes ago 219MB

Nice. About 83 megs now rather than 219 megs for a Hello World web app. Now the idea of a microservice is more feasible!

Please do head over to the GitHub issue here https://github.com/dotnet/dotnet-docker-nightly/issues/500 and offer your thoughts and results as you test these Alpine images. Also, are you interested in a "-debian-slim?" It would be halfway to Alpine but not as heavy as just -debian.

Lots of great stuff happening around .NET and Docker. Be sure to also check out Jeff Fritz's post on creating a minimal ASP.NET Core Windows Container to see how you can squish .(full) Framework applications running on Windows containers as well. For example, the Windows Nano Server images are just 93 megs compressed.


Sponsor: Get the latest JetBrains Rider preview for .NET Core 2.0 support, Value Tracking and Call Tracking, MSTest runner, new code inspections and refactorings, and the Parallel Stacks view in debugger.



© 2017 Scott Hanselman. All rights reserved.
     

Lightweight bundling, minifying, and compression, for CSS and JavaScript with ASP.NET Core and Smidge

Yesterday I blogged about WebOptimizer, a minifier that Mads Kristensen wrote for ASP.NET Core. A few people mentioned that Shannon Deminick also had a great minifier for ASP.NET Core. Shannon has a number of great libraries on his GitHub https://githu…

Yesterday I blogged about WebOptimizer, a minifier that Mads Kristensen wrote for ASP.NET Core. A few people mentioned that Shannon Deminick also had a great minifier for ASP.NET Core. Shannon has a number of great libraries on his GitHub https://github.com/Shazwazza including not just "Smidge" but also Examine, an indexing system, ClientDependency for managing all your client side assets, and Articulate, a blog engine built on Umbraco.

Often when there's more than one way to do things, but one of the ways is made by a Microsoft employee like Mads - even if it's in his spare time - it can feel like inside baseball or an unfair advantage. The same would apply if I made a node.js library but a node.js core committer also made a similar one. Many things can affect whether an open source library "pops," and it's not always merit. Sometimes it's locale/location, niceness of docs, marketing, word of mouth, website. Both Mads and Shannon and a dozen other people are all making great libraries and useful stuff. Sometimes people are aware of other projects and sometimes they aren't. At some point a community wants to "pick a winner" but even as I write this blog post, someone else we haven't met yet is likely making the next great bundler/minifier. And that's OK!

I'm going to take a look at Shannon Deminck's "Smidge" in this post. Smidge has been around as a runtime bundler since the beginning of ASP.NET Core even back when DNX was a thing, if you remember that. Shannon's been updating the library as ASP.NET Core has evolved, and it's under active development.

Smidge supports minification, combination, compression for JS/CSS files and features a fluent syntax for creating and configuring bundles

I'll start from "dotnet new mvc" and then:

C:\Users\scott\Desktop\smidgenweb>dotnet add package smidge

Writing C:\Users\scott\AppData\Local\Temp\tmp325B.tmp
info : Adding PackageReference for package 'smidge' into project 'C:\Users\scott\Desktop\smidgenweb\smidgenweb.csproj'.
log : Restoring packages for C:\Users\scott\Desktop\smidgenweb\smidgenweb.csproj...
...SNIP...
log : Installing Smidge 3.0.0.
info : Package 'smidge' is compatible with all the specified frameworks in project 'C:\Users\scott\Desktop\smidgenweb\smidgenweb.csproj'.
info : PackageReference for package 'smidge' version '3.0.0' added to file 'C:\Users\scott\Desktop\smidgenweb\smidgenweb.csproj'.

Then I'll update appSettings.json (where logging lives) and add Smidge's config:

{

"Logging": {
"IncludeScopes": false,
"LogLevel": {
"Default": "Warning"
}
},
"smidge": {
"dataFolder" : "App_Data/Smidge",
"version" : "1"
}
}

Let me squish my CSS, so I'll make a bundle:

app.UseSmidge(bundles =>

{
bundles.CreateCss("my-css", "~/css/site.css");
});

I refer to the bundle by name and the Smidge tag helper turns this:

<link rel="stylesheet" href="http://feeds.hanselman.com/~/t/0/0/scotthanselman/~my-css" /> 

into this

<link href="http://feeds.hanselman.com/~/t/0/0/scotthanselman/~https://www.hanselman.com/sb/my-css.css.v1" rel="stylesheet" />

Notice the generated filename with version embedded. That bundle could be one or more files, a whole folder, whatever you need.

Her eyou can see Kestral handling the request. Smidge jumps in there and does its thing, then the bundle is cached for the next request!

info: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[1]

Executing action method Smidge.Controllers.SmidgeController.Bundle (Smidge) with arguments (Smidge.Models.BundleRequestModel) - ModelState is Valid
dbug: Smidge.Controllers.SmidgeController[0]
Processing bundle 'my-css', debug? False ...
dbug: Smidge.FileProcessors.PreProcessManager[0]
Processing file '/css/site.css', type: Css, cacheFile: C:\Users\scott\Desktop\smidgenweb\App_Data\Smidge\Cache\SONOFHEXPOWER\1\bb8368ef.css, watching? False ...
dbug: Smidge.FileProcessors.PreProcessManager[0]
Processed file '/css/site.css' in 19ms
dbug: Smidge.Controllers.SmidgeController[0]
Processed bundle 'my-css' in 73ms
info: Microsoft.AspNetCore.Mvc.Internal.VirtualFileResultExecutor[1]
Executing FileResult, sending file

The minified results are cached wherever you want (remember I said App_Data):

Compressed JS and CSS

This is a SUPER simple example. You can use Smidge's fluent interface to affect how an individual bundle is created and behaves:

bundles.CreateJs("test-bundle-3", "~/Js/Bundle3")

.WithEnvironmentOptions(BundleEnvironmentOptions.Create()
.ForDebug(builder => builder
.EnableCompositeProcessing()
.EnableFileWatcher()
.SetCacheBusterType<AppDomainLifetimeCacheBuster>()
.CacheControlOptions(enableEtag: false, cacheControlMaxAge: 0))
.Build()
);

Smidge is unique in its Custom Pre-Processing Pipeline. Similar to ASP.NET Core itself, if there's anything you don't like or any behavior you want to change, you can.

I'm sure Shannon would appreciate help in Documentation and Open Issues, so go check out Smidge at https://github.com/Shazwazza/Smidge!


Sponsor: Check out JetBrains Rider: a new cross-platform .NET IDE. Edit, refactor, test and debug ASP.NET, .NET Framework, .NET Core, Xamarin or Unity applications. Learn more and download a 30-day trial!



© 2017 Scott Hanselman. All rights reserved.
     

WebOptimizer – a Bundler and Minifier for ASP.NET Core

ASP.NET Core didn’t have a runtime bundler like previous versions of ASP.NET. This was a bummer as I was a fan. Fortunately Mads Kristensen created one and put it on GitHub, called WebOptimizer. WebOptimizer – ASP.NET Core middleware for bundling and …

ASP.NET Core didn't have a runtime bundler like previous versions of ASP.NET. This was a bummer as I was a fan. Fortunately Mads Kristensen created one and put it on GitHub, called WebOptimizer.

WebOptimizer - ASP.NET Core middleware for bundling and minification of CSS and JavaScript files at runtime. With full server-side and client-side caching to ensure high performance.

I'll try it out on a default ASP.NET Core 2.0 app.

First, assuming I've installed http://dot.net I'll run

C:\Users\scott\Desktop> cd squishyweb


C:\Users\scott\Desktop\squishyweb> dotnet new mvc
The template "ASP.NET Core Web App (Model-View-Controller)" was created successfully.
This template contains technologies from parties other than Microsoft, see https://aka.ms/template-3pn for details.

SNIP

Restore succeeded.

Then I'll add a reference to the WebOptimizer package. Be sure to check the versioning and pick the one you want, or use the latest.

C:\Users\scott\Desktop\squishyweb> dotnet add package LigerShark.WebOptimizer.Core --version 1.0.178-beta 

Add the service in ConfigureServices and add it (I'll do it conditionally, only when in Production) in Configure. Notice I had to put it before UseStaticFiles() because I want it to get the first chance at those requests.

public void ConfigureServices(IServiceCollection services)

{
services.AddMvc();
services.AddWebOptimizer();
}

// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
app.UseWebOptimizer();
app.UseExceptionHandler("/Home/Error");
}

app.UseStaticFiles();

app.UseMvc(routes =>
{
routes.MapRoute(
name: "default",
template: "{controller=Home}/{action=Index}/{id?}");
});
}

After running "dotnet run" I'll request site.css as an example and see it's automatically minimized:

CSS minification automatically

You can control the pipeline with globbing like this:

public void ConfigureServices(IServiceCollection services)

{
services.AddMvc();
services.AddWebOptimizer(pipeline =>
{
pipeline.MinifyJsFiles("js/a.js", "js/b.js", "js/c.js");
});
}

If I wanted to combine some files into an output "file" that'll be held/cached only in memory, I can do that also. To be clear, it'll never touch the disk, it's just a URL. Then I can just refer to it with a <link> within my Razor Page or main Layout.

services.AddWebOptimizer(pipeline =>

{
pipeline.AddCssBundle("/css/mybundle.css", "css/*.css");
});

WebOptimizer also supports automatic "cache busting" with a ?v= query string created by a TagHelper. It can even compile Scss (Sass) files into CSS. There's plugins for TypeScript, Less, and Markdown too!

WebOptimizer is open source and lives at https://github.com/ligershark/WebOptimizer. Go check it out, kick the tires, and see if it meets your needs! Maybe get involved and make a fix or help with docs! There are already some open issues you could start helping with.


Sponsor: Check out JetBrains Rider: a new cross-platform .NET IDE. Edit, refactor, test and debug ASP.NET, .NET Framework, .NET Core, Xamarin or Unity applications. Learn more and download a 30-day trial!



© 2017 Scott Hanselman. All rights reserved.
     

Optimizing ASP.NET Core Docker Image sizes

There is a great post from Steve Laster in 2016 about optimizing ASP.NET Docker Image sizes. Since then Docker has added multi-stage build files so you can do more in one Dockerfile…which feels like one step even though it’s not. Containers are about…

ASP.NET Core on KubernetesThere is a great post from Steve Laster in 2016 about optimizing ASP.NET Docker Image sizes. Since then Docker has added multi-stage build files so you can do more in one Dockerfile...which feels like one step even though it's not. Containers are about easy and reliable deployment, and they're also about density. You want to use as little memory as possible, sure, but it also is nice to make them as small as possible so you're not spending time moving them around the network. The size of the image file can also affect startup time for the container. Plus it's just tidy.

I've been building a little 6 node Raspberry Pi (ARM) Kubenetes Cluster on my desk - like you do - this week, and I noticed that my image sizes were a little larger than I'd like. This is a bigger issue because it's a relatively low-powered system, but again, why carry around x unnecessary megabytes if you don't have to?

Alex Ellis has a great blog on building .NET Core apps for Raspberry Pi along with a YouTube video. In his video and blog he builds a "Console.WriteLine()" console app, which is great for OpenFaas (open source serverless platform) but I wanted to also have ASP.NET Core apps on my Raspberry Pi k8s cluster. He included this as a "challenge" in his blog, so challenge accepted! Thanks for all your help and support, Alex!

ASP.NET Core on Docker (on ARM)

First I make a basic ASP.NET Core app. I could do a Web API, but this time I'll do an MVC one with Razor Pages. To be clear, they are the same thing just with different starting points. I can always add pages or add JSON to either, later.

I start with "dotnet new mvc" (or dotnet new razor, etc). I'm going to be running this in Docker, managed by Kuberenetes, and while I can always change the WebHost in Program.cs to change how the Kestrel web server starts up like this:

WebHost.CreateDefaultBuilder(args)

.UseUrls(http://*:5000;http://localhost:5001;https://hostname:5002)

For Docker use cases it's easier to change the listening URL with an Environment Variable. Sure, it could be 80, but I like 5000. I'll set the ASPNETCORE_URLS environment variable to http://+:5000 when I make the Dockerfile.

Optimized MultiStage Dockerfile for ASP.NET

There's a number of "right" ways to do this, so you'll want to think about your scenarios. You'll see below that I'm using ARM (because Raspberry Pi) so if you see errors running your container like "qemu: Unsupported syscall: 345" then you're trying to run an ARM image on x86/x64. I'm going to be building an ARM container from Windows but I can't run it here. I have to push it to a container registry and then tell my Raspberry Pi cluster to pull it down and THEN it'll run, over there.

Here's what I have so far. NOTE there are some things commented out, so be conscious. This is/was a learning exercise for me. Don't you copy/paste unless you know what's up! And if there's a mistake, here's a GitHub Gist of my Dockerfile for you to change and improve.

It's important to understand that .NET Core has an SDK with build tools and development kits and compilers and stuff, and then it has a runtime. The runtime doesn't have the "make an app" stuff, it only has the "run an app stuff." There is not currently an SDK for ARM so that's a limitation that we are (somewhat elegantly) working around with the multistage build file. But, even if there WAS an SDK for ARM, we'd still want to use a Dockerfile like this because it's more efficient with space and makes a smaller image.

Let's break this down. There are two stages. The first FROM is the SDK image that builds the code. We're doing the build inside Docker - which is lovely, and  great reliable way to do builds.

PRO TIP: Docker is smart about making intermediate images and doing the least work, but it's useful if we (the authors) do the right thing as well to help it out.

For example, see where we COPY the .csproj over and then do a "dotnet restore"? Often you'll see folks do a "COPY . ." and then do a restore. That doesn't allow Docker to detect what's changed and you'll end up paying for the restore on EVERY BUILD.

By making this two steps - copy the project, restore, copy the code, this means your "dotnet restore" intermediate step will be cached by Docker and things will be WAY faster.

After you build, you'll do a publish. If you know the destination like I do (linux-arm) you can do a RID (runtime id) publish that is self-contained with -r linux-arm (or debian, or whatever) and you'll get a complete self-contained version of your app.

Otherwise, you can just publish your app's code and use a .NET Core runtime image to run it. Since I'm using a complete self-contained build for this image, it would be overkill to ALSO include the .NET runtime. If you look at the Docker hub for Microsoft/dotnet You'll see images called "deps" for "dependencies." Those are images that sit on top of debian that include the things .NET needs to run - but not .NET itself.

The stack of images looks generally like this (for example)

  • FROM debian:stretch
  • FROM microsoft/dotnet:2.0-runtime-deps
  • FROM microsoft/dotnet:2.0-runtime

So you have your base image, your dependencies, and your .NET runtime. The SDK image would include even more stuff since it needs to build code. Again, that's why we use that for the "as builder" image and then copy out the results of the compile and put them in another runtime image. You get the best of all worlds.

FROM microsoft/dotnet:2.0-sdk as builder  


RUN mkdir -p /root/src/app/aspnetcoreapp
WORKDIR /root/src/app/aspnetcoreapp

#copy just the project file over
# this prevents additional extraneous restores
# and allows us to re-use the intermediate layer
# This only happens again if we change the csproj.
# This means WAY faster builds!
COPY aspnetcoreapp.csproj .
#Because we have a custom nuget.config, copy it in
COPY nuget.config .
RUN dotnet restore ./aspnetcoreapp.csproj

COPY . .
RUN dotnet publish -c release -o published -r linux-arm

#Smaller - Best for apps with self-contained .NETs, as it doesn't include the runtime
# It has the *dependencies* to run .NET Apps. The .NET runtime image sits on this
FROM microsoft/dotnet:2.0.0-runtime-deps-stretch-arm32v7

#Bigger - Best for apps .NETs that aren't self-contained.
#FROM microsoft/dotnet:2.0.0-runtime-stretch-arm32v7

# These are the non-ARM images.
#FROM microsoft/dotnet:2.0.0-runtime-deps
#FROM microsoft/dotnet:2.0.0-runtime

WORKDIR /root/
COPY --from=builder /root/src/app/aspnetcoreapp/published .
ENV ASPNETCORE_URLS=http://+:5000
EXPOSE 5000/tcp
# This runs your app with the dotnet exe included with the runtime or SDK
#CMD ["dotnet", "./aspnetcoreapp.dll"]
# This runs your self-contained .NET Core app. You built with -r to get this
CMD ["./aspnetcoreapp"]

Notice also that I have a custom nuget.config, so if you do also you'll need to make sure that's available at build time for dotnet restore to pick up all packages.

I've included by commented out a bunch of the FROMs in the second stage. I'm using just the ARM one, but I wanted you to see the others.

Once we have the code we build copied into our runtime image, we set our environment variable so our all listens on port 5000 internally (remember that from above?) Then we run our app. Notice that you can run it with "dotnet foo.dll" if you have the runtime, but if you are like me and using a self-contained build, then you'll just run "foo."

To sum up:

  • Build with FROM microsoft/dotnet:2.0-sdk as builder
  • Copy the results out to a runtime
  • Use the right runtime FROM for you
    • Right CPU architecture?
    • Using the .NET Runtime (typical) or using a self-contained build (less so)
  • Listening on the right port (if a web app)?
  • Running your app successfully and correctly?

Optimizing a little more

There are a few pre-release "Tree Trimming" tools that can look at your app and remove code and binaries that you are not calling. I included Microsoft.Packaging.Tools.Trimming as well to try it out and get even more unused code out of my final image by just adding a package to my project.

Step 8/14 : RUN dotnet publish -c release -o published -r linux-arm /p:LinkDuringPublish=true

---> Running in 39404479945f
Microsoft (R) Build Engine version 15.4.8.50001 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

Trimmed 152 out of 347 files for a savings of 20.54 MB
Final app size is 33.56 MB
aspnetcoreapp -> /root/src/app/aspnetcoreapp/bin/release/netcoreapp2.0/linux-arm/aspnetcoreapp.dll
Trimmed 152 out of 347 files for a savings of 20.54 MB
Final app size is 33.56 MB

If you run docker history on your final image you can see exactly where the size comes from. If/when Microsoft switches from a Debian base image to an Alpine one, this should get even smaller.

C:\Users\scott\Desktop\k8s for pi\aspnetcoreapp>docker history c60

IMAGE CREATED CREATED BY SIZE COMMENT
c6094ca46c3b 3 minutes ago /bin/sh -c #(nop) CMD ["dotnet" "./aspnet... 0B
b7dfcf137587 3 minutes ago /bin/sh -c #(nop) EXPOSE 5000/tcp 0B
a5ba51b91d9d 3 minutes ago /bin/sh -c #(nop) ENV ASPNETCORE_URLS=htt... 0B
8742269735bc 3 minutes ago /bin/sh -c #(nop) COPY dir:cc64bd3b9bacaeb... 56.5MB
28c008e38973 3 minutes ago /bin/sh -c #(nop) WORKDIR /root/ 0B
4bafd6e2811a 4 hours ago /bin/sh -c apt-get update && apt-get i... 45.4MB
<missing> 3 weeks ago /bin/sh -c #(nop) CMD ["bash"] 0B
<missing> 3 weeks ago /bin/sh -c #(nop) ADD file:8b7cf813a113aa2... 85.7MB

Here is the evolution of my Dockerfile as I made changes and the final result got smaller and smaller. Looks like 45 megs trimmed with a little work or about 20% smaller.

C:\Users\scott\Desktop\k8s for pi\aspnetcoreapp>docker images | find /i "aspnetcoreapp"

shanselman/aspnetcoreapp 0.5 c6094ca46c3b About a minute ago 188MB
shanselman/aspnetcoreapp 0.4 083bfbdc4e01 12 minutes ago 196MB
shanselman/aspnetcoreapp 0.3 fa053b4ee2b4 About an hour ago 199MB
shanselman/aspnetcoreapp 0.2 ba73f14e29aa 4 hours ago 207MB
shanselman/aspnetcoreapp 0.1 cac2f0e3826c 3 hours ago 233MB

Later I'll do a blog post where I put this standard ASP.NET Core web app into Kubernetes using this YAML description and scale it out on the Raspberry Pi. I'm learning a lot! Thanks to Alex Ellis and Glenn Condron and Jessie Frazelle for their time!


Sponsor: Create powerful Web applications to manage each step of a document’s life cycle with DocuVieware HTML5 Viewer and Document Management Kit. Check our demos to acquire, scan, edit, annotate 100+ formats, and customize your UI!



© 2017 Scott Hanselman. All rights reserved.
     

Learning about the F# SAFE stack – Suave.io, Azure, Fable, Elmish

Last month I looked at a Functional Web with ASP.NET Core and F#’s Giraffe. Giraffe is F# middleware that takes ASP.NET Core’s pipeline in a new direction with a functional perspective. However, Giraffe isn’t the only F# web stack to choose from! There…

Last month I looked at a Functional Web with ASP.NET Core and F#'s Giraffe. Giraffe is F# middleware that takes ASP.NET Core's pipeline in a new direction with a functional perspective. However, Giraffe isn't the only F# web stack to choose from! There's Freya, WebSharper, and there's also a very interesting and quite complete story with The SAFE Stack.

The SAFE Stack

The SAFE Stack is an open source stack, like LAMP, or WAMP, or other acronym stacks, except this one is all open source .NET with a functional perspective. From the announcement blog:

  • Suave model for server-side web programming
  • Azure for cloud-based systems
  • Fable for Javascript-enabled applications.
  • Elmish for an easy-to-understand UI programming mode

To be clear, while this is a prescriptive stack, it's not a stack that forces you to do anything. You can swap bits out as you please.

Fable is particularly interesting as it's an F# to JavaScript transpiler. Try Fable online here http://fable.io/repl and turn F# into JavaScript LIVE! Their Sudoku sample is particularly impressive.

Here's two small - but interesting - examples where F# code ends up as JavaScript which ends up creating ReactJS components:

let words size message =
    R.span [ Style [ !!("fontSize", size |> sprintf "%dpx") ] ] [ R.str message ]
let buttonLink cssClass onClick elements = 
    R.a [ ClassName cssClass
          OnClick (fun _ -> onClick())
          OnTouchStart (fun _ -> onClick())
          Style [ !!("cursor", "pointer") ] ] elements

Then later in a Menu.fs that also turns into JavaScript eventually, you can see where they conditionally render the Button for logout, or links for for other Views for the Home Page or Wishlist. You can read lots more about Fable over at the Compositional IT blog.

let view (model:Model) dispatch =
    div [ centerStyle "row" ] [ 
          yield viewLink Home "Home"
          if model.User <> None then 
              yield viewLink Page.WishList "Wishlist"
          if model.User = None then 
              yield viewLink Login "Login" 
          else 
              yield buttonLink "logout" (fun _ -> dispatch Logout) [ str "Logout" ]
        ]

Elmish for F# takes the Model View Update (MVU) architecture and brings it to F# and the browser. There's a good breakdown of the value Elmish provides also at the Compositional IT blog.

Suave is its own cross platform Web Server. Here's Hello World in Suave.

open Suave


startWebServer defaultConfig (Successful.OK "Hello World!")

Suave has been around for while and gets better all the time. I blogged about it in 2015 and got it running on Azure. My blog post is not a best practice any more - it was a spike attempt by me - and fortunately they've moved on and improved things.

Here's Suave getting set up within the sample app. Check out how they route HTTP Verbs and URL paths.

    let serverConfig =
        { defaultConfig with
            logger = Targets.create LogLevel.Debug [|"ServerCode"; "Server" |]
            homeFolder = Some clientPath
            bindings = [ HttpBinding.create HTTP (IPAddress.Parse "0.0.0.0") port] }
    let app =
        choose [
            GET >=> choose [
                path "/" >=> Files.browseFileHome "index.html"
                pathRegex @"/(public|js|css|Images)/(.*)\.(css|png|gif|jpg|js|map)" >=> Files.browseHome
                path "/api/wishlist/" >=> WishList.getWishList loadFromDb ]
            POST >=> choose [
                path "/api/users/login" >=> Auth.login
                path "/api/wishlist/" >=> WishList.postWishList saveToDb
            ]
            NOT_FOUND "Page not found."
        ] >=> logWithLevelStructured Logging.Info logger logFormatStructured
    startWebServer serverConfig app

Very interesting stuff! There are so many options in .NET open source. I'll be doing podcasts on this stack soon.

Trying out the SAFE Stack

If you're using Visual Studio Community 2017, make sure you've got F# support included. I double-checked under Individual components. You can run the VS2017 installer multiple time and add and remove stuff without breaking things, so don't worry. If you are using other versions of VS, check here http://fsharp.org/use/windows/ to get the right download for your machine. If you're using Visual Studio Code, you'll want the Ionide F# plugin for Code.

Adding F# to Visual Studio Community 2017

Once I had node and yarn installed, it was easy to try out the sample app and get it running locally with "build run." It uses DotNetWatcher, so you can just keep it running in the background and work on your code and it'll recompile and restart as you go.

The SAFE stack running

The complete "SAFE" stack demo website is LIVE here http://fable-suave.azurewebsites.net (login test/test/) and all the source code for the app is here: https://github.com/SAFE-Stack/SAFE-BookStore.


Sponsor: Do you know how many errors, crashes and performance issues your users are experiencing? Raygun installs in minutes. Discover problems you didn't even know about and replicate bugs with greater speed and accuracy. Learn more!



© 2017 Scott Hanselman. All rights reserved.
     

Free .NET Training – The Videos from .NET Conf 2017 are now available

.NET Conf 2017 is done and it was great. We had three days of sessions, and two of the days had two tracks, so there’s more than 40 hours of great free videos and training for you to check out and share. Some of the content was from Microsoft but a bun…

.NET Conf was worldwide this year.NET Conf 2017 is done and it was great. We had three days of sessions, and two of the days had two tracks, so there's more than 40 hours of great free videos and training for you to check out and share. Some of the content was from Microsoft but a bunch of the videos were from community and open source project members who Skyped into the studio! While I was in Redmond, Washington, Miguel de Icaza and Scott Hunter did a keynote from Devintersection in Stockholm.

There were also a number of local dotNetConf events! I hope you consider hosting one in your locale next year! While the virtual conference was filmed and broadcast LIVE, all the session videos are posted now at https://channel9.msdn.com/Events/dotnetConf/2017. There's 46 videos but here's a few of my favorites.

Containerized ASP.NET Core Apps with Kubernetes

Mete Atemal from Google joined us to talk about Containerized ASP.NET Core Apps with Kubernetes

image

Build Your Own Cortana Skill

Dorene Brown showed us how to wrote a Cortana skill in C# and .NET.

image

What's New in Visual Studio 2017

Kasey does a deep drive into a TON of the more advanced VS2017 features.

image

Diagnostics 101

The Legend himself, Jon Skeet, does a fantastic code-heavy talk on how to diagnose your app when things go wrong.

image

Go Serverless with Azure Functions and C#

Cecil Phillip breaks down the "serverless" buzzword and shows you how to use Azure Functions.

image

Get started with F# and .NET Core

Phillip Carter is geeked about F# and you should be too!

image

Full Stack F# with Fable

Once you've gotten started with F#, take a look at Fable and start writing Full Stack F# with F# on both the server and client!

image

Turning software into computer chips with Hastlayer

Zoltan explains to me how to use Hastlayer to transform .NET software into electronic circuits on FPGAs!

    image

    Getting Started with .NET

    And finally, last but not least, Kathleen Dollard and I did two hours (part 1 and part 2) on:

    image

    This is just a taste, there's a LOT of great videos so go explore!


    Sponsor: Do you know how many errors, crashes and performance issues your users are experiencing? Raygun installs in minutes. Discover problems you didn't even know about and replicate bugs with greater speed and accuracy. Learn more!



    © 2017 Scott Hanselman. All rights reserved.
         

    The Book of the Runtime – The internals of the .NET Runtime that you won’t find in the documentation

    The Microsoft Docs at https://docs.microsoft.com are really fantastic lately. All the .NET Docs are on GitHub https://github.com/dotnet/docs/ and you can contribute to them. However, in the world of software engineering (here some a bad, mixed metaphor) there’s instructions on how to use a faucet and there’s instructions on how to build and design plumbing from scratch.

    RyuJIT High level overview

    There’s additional DEEP docs that don’t really belong on the docs site. It’s the Book of the Runtime and for now it’s on GitHub. Here’s the BotR FAQ.

    If you’re interested in the internals of a system like the .NET Runtime, these docs are a gold mine for you.

    The Book of the Runtime is a set of documents that describe components in the CLR and BCL. They are intended to focus more on architecture and invariants and not an annotated description of the codebase.

    It was originally created within Microsoft in ~ 2007, including this document. Developers were responsible to document their feature areas. This helped new devs joining the team and also helped share the product architecture across the team.

    We realized that the BotR is even more valuable now, with CoreCLR being open source on GitHub. We are publishing BotR chapters to help a new set of CLR developers.

    This book likely isn’t for you if you’re an app developer. Who is it for?

    • Developers who are working on bugs that impinge on an area and need a high level overview of the component.
    • Developers working on new features with dependencies on a component need to know enough about it to ensure the new feature will interact correctly with existing components.
    • New developers need this chapter to maintain a given component.

    These aren’t design documents, these are docs that were written after features are implemented in order to explain how they work in practice.

    Recently Carol Eidt wrote an amazing walkthrough to .NET Core’s JIT engine. Perhaps start at the JIT Overview and move to the deeper walkthrough. Both are HUGELY detailed and a fascinating read if you’re interested in how .NET makes Dynamic Code Execution near-native speed with the RyuJIT – the next-gen Just in Time compiler.

    Here’s a few highlights I enjoyed but you should read the whole thing yourself. It covers the high level phases and then digs deeper into the responsibilities of each. You also get a sense of why the RyuJIT is NOT the same JITter from 15+ years ago – both the problem space and processors have changed.

    This is the 10,000 foot view of RyuJIT. It takes in MSIL (aka CIL) in the form of byte codes, and the Importer phase transforms these to the intermediate representation used in the JIT. The IR operations are called “GenTrees�, as in “trees for code generation�. This format is preserved across the bulk of the JIT, with some changes in form and invariants along the way. Eventually, the code generator produces a low-level intermediate called InstrDescs, which simply capture the instruction encodings while the final mappings are done to produce the actual native code and associated tables.

    ryujit-phase-diagram

    This is just one single comprehensive doc in a collection of documents. As for the rest of the Book of the Runtime, here’s the ToC as of today, but there may be new docs in the repository as it’s a living book.

    Check it out!


    Sponsor: Check out JetBrains Rider: a new cross-platform .NET IDE. Edit, refactor, test and debug ASP.NET, .NET Framework, .NET Core, Xamarin or Unity applications. Learn more and download a 30-day trial!


    © 2017 Scott Hanselman. All rights reserved.
         

    The Microsoft Docs at https://docs.microsoft.com are really fantastic lately. All the .NET Docs are on GitHub https://github.com/dotnet/docs/ and you can contribute to them. However, in the world of software engineering (here some a bad, mixed metaphor) there's instructions on how to use a faucet and there's instructions on how to build and design plumbing from scratch.

    RyuJIT High level overview

    There's additional DEEP docs that don't really belong on the docs site. It's the Book of the Runtime and for now it's on GitHub. Here's the BotR FAQ.

    If you're interested in the internals of a system like the .NET Runtime, these docs are a gold mine for you.

    The Book of the Runtime is a set of documents that describe components in the CLR and BCL. They are intended to focus more on architecture and invariants and not an annotated description of the codebase.

    It was originally created within Microsoft in ~ 2007, including this document. Developers were responsible to document their feature areas. This helped new devs joining the team and also helped share the product architecture across the team.

    We realized that the BotR is even more valuable now, with CoreCLR being open source on GitHub. We are publishing BotR chapters to help a new set of CLR developers.

    This book likely isn't for you if you're an app developer. Who is it for?

    • Developers who are working on bugs that impinge on an area and need a high level overview of the component.
    • Developers working on new features with dependencies on a component need to know enough about it to ensure the new feature will interact correctly with existing components.
    • New developers need this chapter to maintain a given component.

    These aren't design documents, these are docs that were written after features are implemented in order to explain how they work in practice.

    Recently Carol Eidt wrote an amazing walkthrough to .NET Core's JIT engine. Perhaps start at the JIT Overview and move to the deeper walkthrough. Both are HUGELY detailed and a fascinating read if you're interested in how .NET makes Dynamic Code Execution near-native speed with the RyuJIT - the next-gen Just in Time compiler.

    Here's a few highlights I enjoyed but you should read the whole thing yourself. It covers the high level phases and then digs deeper into the responsibilities of each. You also get a sense of why the RyuJIT is NOT the same JITter from 15+ years ago - both the problem space and processors have changed.

    This is the 10,000 foot view of RyuJIT. It takes in MSIL (aka CIL) in the form of byte codes, and the Importer phase transforms these to the intermediate representation used in the JIT. The IR operations are called “GenTrees�, as in “trees for code generation�. This format is preserved across the bulk of the JIT, with some changes in form and invariants along the way. Eventually, the code generator produces a low-level intermediate called InstrDescs, which simply capture the instruction encodings while the final mappings are done to produce the actual native code and associated tables.

    ryujit-phase-diagram

    This is just one single comprehensive doc in a collection of documents. As for the rest of the Book of the Runtime, here's the ToC as of today, but there may be new docs in the repository as it's a living book.

    Check it out!


    Sponsor: Check out JetBrains Rider: a new cross-platform .NET IDE. Edit, refactor, test and debug ASP.NET, .NET Framework, .NET Core, Xamarin or Unity applications. Learn more and download a 30-day trial!



    © 2017 Scott Hanselman. All rights reserved.
         

    A Functional Web with ASP.NET Core and F#’s Giraffe

    728331198_7c1854e363_bI was watching Ody Mbegbu’s YouTube Channel – it’s filled with .NET Core and ASP.NET Tutorial Videos – and was checking out one in particular, “Getting Started with ASP.NET Core Giraffe.” Dane Vinson pointed me to it.

    There is such a great open source renaissance happening right now with new framework’s and libraries popping up in the .NET Core space. I hope you check them out AND support the creators by getting involved, writing docs, filing (kind) issues, and even doing pull requests and fixing bugs or writing tests.

    Ody’s video was about Dustin Morris’ “Giraffe” web framework. Dustin’s description is “A native functional ASP.NET Core web framework for F# developers.” You can check it out over at https://github.com/dustinmoris/Giraffe.

    Even better, it uses the “dotnet new” templating system so you can check it out and get started in seconds.

    c:> md \mygiraffeeapp & cd \mygiraffeeapp
    c:\mygiraffeeapp> dotnet new -i "giraffe-template::*"
    c:\mygiraffeeapp> dotnet new giraffe
    The template "Giraffe Web App" was created successfully.
    c:\mygiraffeeapp> dotnet run
    Hosting environment: Production
    Content root path: C:\mygiraffeapp
    Now listening on: http://localhost:5000
    Application started. Press Ctrl+C to shut down.

    Boom. Now I’m checking out Giraffe’s “Hello World.”

    Because ASP.NET Core is very modular and built on “middleware” pipelines, that means that other frameworks like Giraffe can use the bits they want and remove the bits they down. Remembering that this is F#, not C#, here you can see Giraffe adding itself to the pipeline while still using the StaticFileMiddleware.

    let configureApp (app : IApplicationBuilder) =
    app.UseGiraffeErrorHandler errorHandler
    app.UseStaticFiles() |> ignore
    app.UseGiraffe webApp

    The initial readme.md for Giraffe is the docs for now, and frankly, they are excellent and easy to read. The author says:

    It is not designed to be a competing web product which can be run standalone like NancyFx or Suave, but rather a lean micro framework which aims to complement ASP.NET Core where it comes short for functional developers. The fundamental idea is to build on top of the strong foundation of ASP.NET Core and re-use existing ASP.NET Core building blocks so F# developers can benefit from both worlds.

    Here is a smaller Hello World. Note the use of choose and the clear and terse nature of F#:

    open Giraffe.HttpHandlers
    open Giraffe.Middleware

    let webApp =
    choose [
    route "/ping" >=> text "pong"
    route "/" >=> htmlFile "/pages/index.html" ]

    type Startup() =
    member __.Configure (app : IApplicationBuilder)
    (env : IHostingEnvironment)
    (loggerFactory : ILoggerFactory) =

    app.UseGiraffe webApp

    Is terse an insult? Absolutely not, it’s a feature! Check out this single line exampe…and the fish >=> operator! Some people don’t like it but I think it’s clever.

    let app = route "/" >=> setStatusCode 200 >=> text "Hello World"

    Making more complex:

    let app =
    choose [
    GET >=> route "/foo" >=> text "GET Foo"
    POST >=> route "/foo" >=> text "POST Foo"
    route "/bar" >=> text "Always Bar"
    ]

    Or requiring certain headers:

    let app =
    mustAccept [ "text/plain"; "application/json" ] >=>
    choose [
    route "/foo" >=> text "Foo"
    route "/bar" >=> json "Bar"
    ]

    And you can continue to use Razor views as you like, passing in models written in F#

    open Giraffe.Razor.HttpHandlers

    let model = { WelcomeText = "Hello World" }

    let app =
    choose [
    // Assuming there is a view called "Index.cshtml"
    route "/" >=> razorHtmlView "Index" model
    ]

    There are samples at https://github.com/dustinmoris/Giraffe/tree/master/samples you can check out as well

    * Giraffe photo by Kurt Thomas Hunt, used under CC


    Sponsor: A third of teams don’t version control their database. Connect your database to your version control system with SQL Source Control and find out who made changes, what they did, and why. Learn more!


    © 2017 Scott Hanselman. All rights reserved.
         

    728331198_7c1854e363_bI was watching Ody Mbegbu's YouTube Channel - it's filled with .NET Core and ASP.NET Tutorial Videos - and was checking out one in particular, "Getting Started with ASP.NET Core Giraffe." Dane Vinson pointed me to it.

    There is such a great open source renaissance happening right now with new framework's and libraries popping up in the .NET Core space. I hope you check them out AND support the creators by getting involved, writing docs, filing (kind) issues, and even doing pull requests and fixing bugs or writing tests.

    Ody's video was about Dustin Morris' "Giraffe" web framework. Dustin's description is "A native functional ASP.NET Core web framework for F# developers." You can check it out over at https://github.com/dustinmoris/Giraffe.

    Even better, it uses the "dotnet new" templating system so you can check it out and get started in seconds.

    c:> md \mygiraffeeapp & cd \mygiraffeeapp
    
    c:\mygiraffeeapp> dotnet new -i "giraffe-template::*"
    c:\mygiraffeeapp> dotnet new giraffe
    The template "Giraffe Web App" was created successfully.
    c:\mygiraffeeapp> dotnet run
    Hosting environment: Production
    Content root path: C:\mygiraffeapp
    Now listening on: http://localhost:5000
    Application started. Press Ctrl+C to shut down.

    Boom. Now I'm checking out Giraffe's "Hello World."

    Because ASP.NET Core is very modular and built on "middleware" pipelines, that means that other frameworks like Giraffe can use the bits they want and remove the bits they down. Remembering that this is F#, not C#, here you can see Giraffe adding itself to the pipeline while still using the StaticFileMiddleware.

    let configureApp (app : IApplicationBuilder) =
    
    app.UseGiraffeErrorHandler errorHandler
    app.UseStaticFiles() |> ignore
    app.UseGiraffe webApp

    The initial readme.md for Giraffe is the docs for now, and frankly, they are excellent and easy to read. The author says:

    It is not designed to be a competing web product which can be run standalone like NancyFx or Suave, but rather a lean micro framework which aims to complement ASP.NET Core where it comes short for functional developers. The fundamental idea is to build on top of the strong foundation of ASP.NET Core and re-use existing ASP.NET Core building blocks so F# developers can benefit from both worlds.

    Here is a smaller Hello World. Note the use of choose and the clear and terse nature of F#:

    open Giraffe.HttpHandlers
    
    open Giraffe.Middleware

    let webApp =
    choose [
    route "/ping" >=> text "pong"
    route "/" >=> htmlFile "/pages/index.html" ]

    type Startup() =
    member __.Configure (app : IApplicationBuilder)
    (env : IHostingEnvironment)
    (loggerFactory : ILoggerFactory) =

    app.UseGiraffe webApp

    Is terse an insult? Absolutely not, it's a feature! Check out this single line exampe...and the fish >=> operator! Some people don't like it but I think it's clever.

    let app = route "/" >=> setStatusCode 200 >=> text "Hello World"

    Making more complex:

    let app =
    
    choose [
    GET >=> route "/foo" >=> text "GET Foo"
    POST >=> route "/foo" >=> text "POST Foo"
    route "/bar" >=> text "Always Bar"
    ]

    Or requiring certain headers:

    let app =
    
    mustAccept [ "text/plain"; "application/json" ] >=>
    choose [
    route "/foo" >=> text "Foo"
    route "/bar" >=> json "Bar"
    ]

    And you can continue to use Razor views as you like, passing in models written in F#

    open Giraffe.Razor.HttpHandlers
    

    let model = { WelcomeText = "Hello World" }

    let app =
    choose [
    // Assuming there is a view called "Index.cshtml"
    route "/" >=> razorHtmlView "Index" model
    ]

    There are samples at https://github.com/dustinmoris/Giraffe/tree/master/samples you can check out as well

    * Giraffe photo by Kurt Thomas Hunt, used under CC


    Sponsor: A third of teams don’t version control their database. Connect your database to your version control system with SQL Source Control and find out who made changes, what they did, and why. Learn more!



    © 2017 Scott Hanselman. All rights reserved.