This article is a series on using Dapper in .NET Core. Feel free to jump around, but we highly recommend you start in Part 1 and work your way through!

Part 1 – The What/Why/Who
Part 2 – Dapper Query Basics
Part 3 – Updates/Inserts/Deletes
Part 4 – Dapper Contrib

Installing Dapper

Dapper is a nuget package that does nothing more than “augment” the existing SQLConnection object in .NET Core….. Reading that line back I’m not sure it makes sense but hopefully it will at the end. In simple terms you can install the Dapper nuget package by running the following from your Package Manager Console.

In the following examples I’m just running them from a simple console application, but you can install Dapper into any type of .NET Full Framework/.NET Core application.

Follow Along Data

For much of this tutorial, I’m going to be using some data that I created for a simple “Event” database. There really isn’t much to it, but if you want to follow along at home you can grab the script to create the database/tables/data from this Github Gist here :

It’s not required and for the most part everything we do here will be super simple. But if you want to write the queries in your own console application as we go, that’s cool too!

Creating A Database Connection

As you might have seen earlier, when using Dapper we have to create our own SQL Connection to the database. Dapper doesn’t do this for us. But.. It’s simple enough. For example in a console application that I’ve already installed Dapper from Nuget in, all it takes is :

That’s it! We now have a connection to our database that is “Dapper” ready. You’ll also notice that at this point, the only “Using” statement we would actually be using is using System.Data.SqlClient; . That’s because the SqlConnection object is the regular one from the .NET library, so far we haven’t even used Dapper yet!

Query A Single Row

Let’s add some magic and actually get the above SQL Connection actually doing something. In my example database, I have a table called “Event” that has a list of events in it. I want to know specifically what the name of the event is with the Id of 1.

… That’s it. We can of course write our initial SQL in something like SQL Management Studio, and then copy it across. We have complete control over the query and it’s going to run *exactly* what we told it to.

The actual magic part of this is the “QueryFirst” method on our connection. If we jump into the source code of Dapper we can see this is just an extention method on the SqlConnection object.

That’s part of the beauty of Dapper. It’s using really simple concepts that we already know like SqlConnection, and extending them just a little bit more to be useful.

Query A Table Into An Object

So far we are just returning a single property, a string. That’s not that amazing really. But what if we wanted the full Event object instead. Well… Dapper handles that out of the box too.

First we create a class that maps to our SQL Table :

Then we modify our statement a bit to instead be a SELECT * and instead use the return type of Event instead of string. So it looks like so :

If you’ve ever used raw ADO statements before in .NET, you’ll know the pain of manually mapping each property from the database to our C# class. But Dapper does that all for us. It takes the results from the statement, and checks to see if there is a property with the same name as a column, if there is, great map it! If not, don’t worry, just throw it away for now.

Query Statement Into A DTO

So the above example maps an entire database table to a C# class, but the annoying part of that is maybe we don’t need everything. Infact a very common SQL performance issue is overselecting. In our above example we actually only use the Id and EventName fields, so let’s first create a DTO with only those fields.

Then we can modify our query a bit to only select the columns we need, and make Dapper map it to our DTO :

Too easy!

Using Parameterized Queries

We haven’t really been taking user input at this point. But let’s pretend instead of always getting the Event with the ID of 1, we allowed the user to specify the Id. How can we pass that to our Dapper query while still following best practice (aka parameterizing the query).

Well again, Dapper takes care of this for us :

Pretend that eventId actually came from a GET param or any other user input. All we do is substitute an @VariableName in our SQL statement, then we add a new parameter of an anonymous object where the “Key” is the same as the @VariableName and the value is what you want it to be.

But why couldn’t I just change the line to the following?

Both look like they do substitutions, but the first actually uses proper parameters when executing the SQL statement. If you use a SQL Profiler, you will see the following for the first query :

Notice how the parameter is specified after the query, and yet for the second example where we just use string substitution :

Uh Oh, no parameters here. This opens us up for SQL Injection a plenty. But again, Dapper handles this for us with proper parameterization!

Query Multiple Rows

Up until now, we’ve been querying just a single row at a time. If we want more than one, that’s just as easy :

We just change our “QueryFirst” to a “Query” and away we go! We are instead returned a list of mapped objects which we can cycle through. Pretty easy stuff!

What’s Next

With the basics of querying using Dapper out of the way, obviously reading and writing is up next! You can check that out here!

This article is a series on using Dapper in .NET Core. Feel free to jump around, but we highly recommend you start in Part 1 and work your way through!

Part 1 – The What/Why/Who
Part 2 – Dapper Query Basics
Part 3 – Updates/Inserts/Deletes
Part 4 – Dapper Contrib

For some time now I’ve been a huge fan of using Dapper in both personal and commercial projects. With more and more projects lending themselves to Microservices architecture, or at the very least a large application being made up of many smaller components, Dapper just makes sense.

But I’m getting a little tired of telling the same story of what Dapper is and what it’s capable of doing, so here’s my attempt at a “crash course” in Dapper with .NET Core.

What Is Dapper?

Dapper is classed as a “micro” ORM. That is, it’s an ORM but is extremely lightweight and gives only very basic functionality. Whereas we might class something like Entity Framework or NHibernate as a fully featured heavyweight ORM, Dapper provides minimal overhead and really only helps you out with some core basics.

Put simply, it runs your database queries from your .NET Core code, and returns results in an easy to manage fashion.

Why Dapper?

The core reason people tend to pick Dapper over something like Entity Framework is the control it affords. Under Dapper, gone are the days of using a long complex LINQ queries that generate ghastly SQL that would make any DBA shriek at first sight. Infact, with Dapper you know exactly what SQL is going to be executed…. because you wrote it. As an example, if I have a “Event” table where I want to get the “EventName” of the record with an “Id” of 1. That would look like :

No ambiguity here, I know exactly what’s going to get run.

But that probably leads us to the question of “When should I NOT use Dapper“. And it’s actually a pretty good question. Realistically I think there are two types of developers/projects that mean that Dapper may not be on the cards.

The first is if you are thinking of moving an existing project to Dapper, and that project already makes heavy use of things like EntityTracking in Entity Framework – or really any Entity Framework specific feature, then Dapper may be a stretch. There is no entity tracking to speak of in Dapper – atleast out of the box (It’s all just POCO’s), so if you are expecting some of that EF magic, Dapper isn’t for you.

The second is actually developer specific and I debate if I should even put this in here. When trying to teach junior developers Dapper, they get annoyed that they have to write raw SQL. Personally I think if you are interacting with a database at all you should know SQL to a pretty high degree. But some developers really are just happy using the LINQ they already know and love, and for some the learning curve of ASP.NET Core is large enough without adding in databases to the mix. If that’s you, and you are just getting started with C# and don’t want to learn SQL just yet, then yeah, maybe this isn’t for you.

Who Is Behind Dapper?

The brains behind Dapper are the guys over at StackOverflow. It was created because the burden on the web servers of simply taking the LINQ2SQL statements and generating SQL was often making their web boxes hit 100% CPU. Coupled with the fact that you couldn’t actually control what SQL was output from your LINQ, Dapper was born.

Best of all, Dapper is completely open source. That means you can go check out how things work, and even fix bugs if you feel that way inclined!

Next Time

So with our history lesson out of the way, let’s actually get stuck in and write some simply Dapper statements. Click here to get cracking on Querying With Dapper.

If you’ve started a new ASP.NET Core project recently, chances are you would have seen the following lines :

And chances are, you’ve also followed a tutorial that was written about a year ago that doesn’t include this line and instead has this big long winded builder instead :

Or maybe you could be coming here because you’ve been told to add the following configuration lines somewhere in your code :

But yours just “works” without it. Somehow. Magically.

I know that people comment on old tutorials from 2+ years ago that their boilerplate code no long matches what they get when creating a new project in Visual Studio. I’ve thought about going back and editing all tutorials, but instead I felt it was important to understand the simplicity of what’s going on here and that it’s really not such a big deal.

Let’s demystify.

Opening Up The Code

Before we go much further I have to say that until a few years back, I probably wasn’t as big on the open source train as I could be. But with ASP.NET being open source, I lost count of how many times I just skipped the documentation and went to the actual source code to work out what was going on or how I should approach something. This is one of those times!

We can actually head to the source code for CreateDefaultBuilder and take a look!

I’ve removed a lot of code for brevity. But as we can see, the CreateDefaultBuilder actually adds in both appsettings.json and the appsettings for our current environment. Hence why we don’t see configuration code being required elsewhere!

If we look deeper into the code we can actually see it doing a lot more of the work that we previously had to build ourselves.

What Else Is Done For Us?

When we use the CreateDefaultBuilder method, out of the box we get :

  • Sets the “Content Root” to be the current directory
  • Allows Command Line args to be pushed into your configuration object
  • Adds both appsettings.json and appsettings.{Environment}.json to be loaded into the configuration object
  • Adds environment variables to the configuration object
  • If in Development, allows the loading of secrets.
  • Adds Console/Debug loggers
  • Tells the app to use Kestrel and to load Kestrel configuration from the loaded config
  • Adds Routing
  • Adds IIS Integration

That sounds like a lot, but if we again go back to what we used to write :

It’s just now doing all of this under the hood for us (and more!). Nice!

.NET Core 3.0 Preview 7 has been released as of July 23rd. You can grab it here :

What’s Included

The official post from Microsoft is here : but you’re not going to find anything shiny and new to play with. Infact the post explicitly states “The .NET Core 3.0 release is coming close to completion, and the team is solely focused on stability and reliability now that we’re no longer building new features“. So if something hasn’t made it into .NET Core 3.0 by now, you might be waiting until 3.1.

But that doesn’t mean we can’t take a look at what’s been happening under the hood. So I took a look at the Github issue list to see what did make it to this release, even if it wasn’t worth a shout out in the official blog post. In particular, there seems to be two main areas that has garnered quite a few taggings.

JsonSerializer Bugs

Unsurprisingly with .NET Core moving away from JSON.NET and instead moving to use their own JSON Serializer, there has been bugs a plenty. At a glance, it mostly looks like edgecase stuff where in particular scenarios, serializing and deserializing is not working as expected. Things like JSON Should be able to handle scientific notation.

Blazor Bugs

Blazor has been getting a major push recently – I’m seeing it show up more and more in my twitter feed. And along with people using it for realworld work loads, comes people logging bugs. To be brutally honest, I haven’t used Blazor at all. It feels like it’s trying to solve a problem that doesn’t exist somewhat like the early days of ASP.NET WebForms. (And feel free to drop a comment below about how I’m totally wrong on that!).

Worth Updating?

One thing worth mentioning is that Microsoft say “NET Core 3.0 Preview 7 is supported by Microsoft and can be used in production“. So they obviously feel confident enough that this is a proper Release Candidate. But in terms of getting this because there is something new in there that you definitely need to get a hold of, it’s probably worth skipping for now.

So… This post spun a little out of control. What turned into a hunt for a simple use case (Turn an HTML string into a PDF) turned into a full blown thesis. So here’s some quick links to jump to various parts of the article if you are coming here straight from Google, it may make things a bit easier. But I do highly recommend reading from the start to get an idea of what PDF Generation really looks like on .NET Core.


It’s a pretty common use case to want to generate PDF’s in C# code, either to serve directly to a user or to save locally. When I came to do it recently, suddenly I was over(and under)whelmed with the options available to actually achieve this. Certainly natively, there is nothing in C# or .NET Core that can generate PDF’s for you. And when it came to actually looking at feature sets of third party libraries (e.g. I want to use HTML as a template option), there were all sorts of problems.

So with that being said, instead of giving you code to generate a PDF with a particular PDF library, I’ll talk about how I evaluated each option.

What I Was Looking For

Before I set out on my journey, I wrote down 3 really crucial points that I would judge the libraries on. These aren’t too complex or even that much of an ask (Or so I hoped).


Obviously free is ideal. Something open source that I can debug myself is even better. But if I do have to pay for a “premium” library. I’m looking for a one time fee that isn’t some stupid “per user/seat/machine/server” model. If I’m looking at this library as a company, I don’t want future architecture or decisions to be made based on the pricing of a library.

If there is some sort of freemium model in play, then I also wanted to make sure that the limitations weren’t too crazy (e.g. single pages only, set number of images allowed per PDF). Freemium is OK as long as the free version is actually useable.

HTML Templating (Or something close)

I had already decided that I wanted to use HTML as my templating mechanism. I was open to using some other reasonable alternative (e.g. HTML with some XSLT engine), but ideally I just want to feed an HTML file to the library and out comes my PDF. What I really don’t want to do is have to place each element manually on the PDF like we had to back in the day when printing a document from a WinForms application.

Ease Of Use/All In One

This is probably a pretty subjective one, but when you start seeking out libraries from the corners of the web or that stackoverflow answer from 3 years ago, you often end up getting some really half baked library that just doesn’t work. Whether it’s some C++ library converted to C#, a library that needs X number of other libraries to actually function, or things just plain don’t work how they should, I’m probably going to see it all. So above else, I just want to be up and running in minutes, not hours.

PDF Sharp

First up is PDF Sharp, I feel like I’ve used this one previously but I’m not entirely sure. The whole ____Sharp thing was all the rage in the early days of C#. Anyway straight off the bat PDFSharp does not work with .NET Core. There may be ported versions floating around but the version on Nuget does not support .NET Core. So it’s pretty much dead in the water. But this one was suggested to me over and over so I still want to do a quick write up about it.


PDF Sharp is free and open source. They do offer paid support but don’t give any specifics on how this works and how much it costs. Free is free though so you can’t complain too much.

HTML Templating

Oh boy. HTML Templating doesn’t make it into the PDF Sharp library unfortunately. Instead we are stuck with writing syntax like we are back in the GDI+ dark days of C# :

I get it that this was what you had to do in the year 2000, but it’s just not going to fly right now. There are ways around this using another library that extends PDFSharp… But that’s still another library that you have to grab and work with. So basically, in terms of a decent template engine out of the box, it’s a fail.

Ease Of Use

Well. It doesn’t work with .NET Core which is probably going to be a blocker. The last published version was 2013. And it doesn’t have HTML rendering packaged (And the library that currently does extend it to do HTML templating also doesn’t support .NET Core). So all in all. Forget about it.


I got pushed to SelectPDF by a tonne of stackoverflow answers (Kinda felt like maybe they were astroturfing a little…). It’s a paid library (Which made it all the more annoying they were commenting on stackoverflow answers with “Sure just use this great library called SelectPDF” and not mentioning the cost), But regardless I wanted to check them out and see what they offered.


It ain’t free, that’s for sure. Licensing starts at $499 and goes up to $1599. Interestingly they do offer an online version where they can generate the PDF for you by sending a URL or HTML code. Honestly I think that’s way more interesting as a business model, but the pricing again starts at $19 but goes all the way up to $449 a month so I can’t really see many people taking this option.

EDIT : So weirdly enough, there seems to be a “hidden” free community edition that you can only find via a tiny footer link. You can read more about the Community Edition here. It seems like the only limitation is that you can’t generate PDFs over 5 pages. Doesn’t seem to be any limitation on commercial use. But again, seems strange to only make this a tiny footer link and not sure it anywhere else…

HTML Templating

HTML Templating is definitely here. And it seems to work well. In just a few lines we are up and running. While documentation is pretty good, I found it sort of all over the place. Loading HTML from a string versus loading HTML from a URL was all mixed together and so when reading examples, you had to check the code example to see what it was actually used for. But that being said, HTML Templating works so tick!

Ease Of Use

Here’s the code to render HTML :

So on that level, ease of use seems good. I would say that many code examples were done using old school .NET WebForms which made me uneasy. Not sure why but using such an old technology like that doesn’t make me feel like I’m using the best in class.

It’s hard to fault SelectPDF on the actual bones of what it’s doing. It generates PDF’s and does what it says on the tin. But I can’t help but feel like it’s a “budget” option for the price – It’s probably the logo not being transparent.


Last up, IronPDF. These guys create a bunch of libraries called IRON______ so you may have run into them before. I’ve run into them a few times for their OCR library, and that’s unfortunate because as soon as they came up, I knew the pricing was gonna be out of this world.


For starters they have all these tiers. Like you can get a single project license, but you have to pay per developer (ugh). But.. If you are a SAAS company, then you have to pay per user of your SAAS product. If you are developing desktop software or something distributed, well that’s a new license again. But let’s just stick with being a SAAS company for now, for 1000+ users I’m going to be paying $1599USD for the library and a years worth of support.

In fairness, most large companies aren’t going to bat an eye at that. It’s not super crazy, and it is one off, but it’s still pretty pricey.

HTML Templating

Yes and yes. In IronPDF it just works. What impressed me the most about IronPDF was their documentation. It wasn’t just “Here’s a snippet, good luck!”. They even went as far to show you examples of how you might use Handlebars as a templating engine, implementing page breaks in your HTML, and even watermarking. To say that it’s feature rich would be an understatement.

Ease Of Use

Again, IronPDF comes up trumps when it comes to ease of use. In literally 4 lines everything just works and the output PDF is exactly as it should be :

Now here I’m using inline HTML, but I can load an HTML file or load a remote URL even and it still just works. Compared to the other libraries we’ve tried, this one is certainly the best when it comes to ease of use.

The Rest

Here are the other libraries I looked at but didn’t even bother going past the first hurdle (I sort of learnt my lesson after PDFSharp didn’t even work on .NET Core).


This shouldn’t really even be considered on the face of it. WKHTMLTOPDF is actually a binary that can generate PDF’s from HTML files, but there are a bunch of .NET wrappers to make use of it. Just felt odd to me and didn’t feel like a solution as much as it was a bunch of pieces hobbled together that should get you there in the end. Even if you do want to go through that pain, features are rather limited. But it’s free!

Spire PDF

Ridiculous pricing. Starts at $599 for a single developer and goes up to $9000 for over 10 developers. Might be OK for people who hate money but I skipped this one.


Another one for haters of money. Pricing starts at $749 and goes up to $4000. Support for .NET Core also seemed extremely sketchy. With the documentation half saying they support .NET Core, but to target Full Framework.

Aspose PDF

You guessed it, another one with ridiculous pricing. Starts at $999 and goes up to $14000 (Fourteen thousand) for an OEM license that still only allows 10 developers. Of course if you want the enterprise support edition you’re going up to $22000 (Twenty two thousand). Pass.

ITextSharp/IText 7

Hidden pricing which typically means “enterprise” priced where some salesman will call you to sell you on the library. Seems to work on AGPL license for free applications but rather not get into that.


So after all of that. Where does it leave us? Honestly in my opinion the only valid option right now to generate PDF’s on .NET Core is IronPDF. I know it costs but relatively speaking, $1500 is actually nothing compared to some of these other libraries. And again in my opinion, it seemed to have the most fully featured API along with the most up to date documentation. If you have another PDF option in .NET Core, feel free to drop a comment below!

EDIT : It’s been pointed out that SelectPDF does have a free community so that’s worth a crack too if you really want something out and out free. But it’s definitely still a two horse race.


In a previous post we looked at how we can publish a single exe from a .NET Core project. Now in it, I talk about how the resulting binary is absolutely massive, 70MB for a simple hello world console app! But I also talked about how there are now ways to significantly chop that down.

Despite that, when shared with Reddit, there was some comments that weren’t so impressed. Most notably this gem :

But that’s cool. For Scellow and anyone else that wasn’t impressed with the size of the exe, let’s look at how we can chop it down.

You Need .NET Core 3.0 (Preview 6+)

Like all these features I’m writing about recently, you’re gonna need the very latest version of .NET Core 3.0. At the time of writing it’s Preview 6. Any version earlier will simply not fly. And again, if that isn’t you and you don’t want to muck around with preview versions, then you’ll just have to wait!

PublishedTrimmed Flag

Before we go on, you might hear IL Linker talked about a lot. Possibly because it’s in the title of this post! But that’s because IL Linker is essentially the backbone of this entire feature. However where previous it was this external tool you had to grab from a nuget feed, now it’s built directly into .NET Core 3.0+ which is pretty impressive!

Anyway we previously published our application using the following command :

And with that, we ended up with an exe over 70MB big :

Not good. But literally all we have to do is add one flag and we can chop it down a bit :

So… 29MB. And this is about the time where you go “but shouldn’t this be KB in size?”. And honestly the answer is yes. It should be. But we have to remember that this is still a completely self contained application that doesn’t even require the target machine to know what .NET Core is. So even if we aren’t using things like say.. cryptography so we can get rid of that, there is probably a lot of basic and primitive .NET Core features that we just can’t get rid of.

Still. It’s an exe half the size with no functional difference between the two.

Reflected Assemblies

Through various forms of reflection, we may end up loading assemblies at runtime that aren’t direct references. Take this (very convoluted) example of loading an assembly at runtime :

Now when debugging this locally, and we have .NET Core installed, we ask for System.Security and it knows what that is because we are using the installed .NET Core platform. So running it, we get :

But if we publish this using the PublishTrimmed flag from the command line, then run it :

Unsurprisingly, we have trimmed a bit too much off. Because I don’t actually reference System.Security anywhere, it’s decided we aren’t actually using it. But there is a way to specify that we know best, and to package it up for us.

All we need to do is edit our csproj file for our project and add :

Now we will bundle up System.Security with our single exe and everything will run smooth! Pretty nice I have to say!

You may ask yourself “Well how will I know when I need to do this?”. Frankly 99% of the time you won’t. If you decide to trim your exe, you will need to really give it a good test before letting it out into the wild.

Getting Setup With C# 8

If you aren’t sure if you are using C# 8, or you know you aren’t and want to know how to access these features. Read this quick guide on getting setup with .NET Core and C# 8. On top of that, you will need atleast .NET Core 3.0 Preview 2 – The preview is important! And then also, atleast for me, I had issues with Visual Studio going crazy and not accepting Switch Expressions but VS Code was OK. Again, this is almost like early access so if you don’t want to deal with the pain now, wait until .NET Core 3.0 and C# 8 is officially released!

Existing Switch Statements

So just in case we aren’t sure what existing Switch statements look like, let’s grab some super basic dummy code. Let’s say I have a Bank class that has a status. And based on this status I want to work out if I can walk into the bank or not.

So I might have a super simple method like so that returns if I can or can’t walk in :

Now I know this is a super obtuse example but I want to point out a couple of things.

I know that in my example, I’m returning the result anyway, but let’s pretend I want to use the value. Mind you, even if I wanted to I can’t do something like result = switch(bank.Status) to set the result. You’ll also notice just how much cruft there is in this example. Each line needs an almost redundant case and break statement even though it’s just doing one thing each.

Switch Expressions

Again I have to stress that this is only for C# 8 and above! But let’s rewrite this as a switch statement :

What the… So straight away look how succinct this is. We can assign the result of our switch statement directly to our variable, and we do away with all of that case/break junk. Pretty nice. Heck we can even rewrite it a bit to return immediately :

Hell if we really wanted to, we could get rid of some curlys as well :

I’ve been kinda critical with some C# features lately. Namely Default Interface Implementations, but.. This just makes sense!

Extending This Further

Finally, I want to just riff a little bit and show you even more of what the switch expression can do and/or look like. Some of these are actually existing features in C# to do with pattern matching, but I thought I would throw them in here because while you’re here, you may as well get them all out of the way incase you haven’t seen them yet. Now some of my examples again will seem a bit overkill, but coming up with specific examples to show all of these is actually pretty hard!

You can use a when  statement to further your switch statement. For example :

But you can also now do something called Tuple Patterns which means passing more than one parameters to the switch statement.

Note that you can use the under score (_) character to signify that it should match anything. In this case because it doesn’t matter whether they are a VIP, if the bank is closed it’s closed, then whatever that value is just match it.

And finally, you actually can now pass objects to a switch statement and inspect their properties!

This is so that instead of creating a Tuple from your properties, you just pass in the single object and you can have multiple matching statements separated by a comma. It’s really awesome stuff!

Say I have a simple “Hello World” console application that I want to send to a friend to run. The friend doesn’t have .NET Core installed so I know I need to build a self contained application for him. Easy, I just run the following command in my project directory :

Pretty self explanatory :

  • Publish the project from the current directory
  • Build the project to run on Windows 64 bit machines
  • Build in release configuration mode
  • Publish everything as “self-contained” so that everything required to run the app is packaged up with our executable

So this works right, we end up with a folder that has our exe and everything that is required to run it, but the issue is that there is a tonne required to run even a HelloWorld console app.

All up it’s a little over 200 files. Crazy – but it makes sense. It’s essentially having to package the .NET Core runtime just to run Hello World.

So functionally, this works. But optics wise, it looks like a mess. I’ve sent folders like this to clients and had to say “uhh.. So I’m going to send you a folder with hundreds of files in it… But… Can you just find the one titled MyApplication.exe and run that and don’t worry about the rest?”. When people are used to having an icon on their desktop they double click and things just.. work… This just doesn’t cut it.

You Need .NET Core 3.0 (Preview 5+)

I need to put that in bold because this will not work if you don’t have .NET Core 3.0. And if you are an early adopter (At the time of this post .NET Core 3.0 is not GA yet), you will need atleast preview 5 upwards. If you’re not one to mess around in preview’s, then you can just wait a few months till .NET Core 3.0 is released!

The PublishSingleFile Flag

All that intro and it literally comes down to a single command flag :

All this does is runs our publish command but tells it to package it within a single file. You’ll notice that we no longer specify the self-contained flag. That’s because it’s assumed that if you are packaging as a single exe, that you will want all it’s dependencies along with it. Makes sense.

And the output :

A single tidy exe! When this is executed, the dependencies are extracted to a temporary directory and then everything is ran from there. It’s essentially a zip of our previous publish folder! I’ve had a few plays around with it and honestly, it just works. There is nothing more to say about it. It just works.

Helpful Tip : Make sure you clean your publish directory or just outright delete your bin folder. It doesn’t break anything to not do so, but all those old DLL’s just hang around until you do so your nice single EXE is hard to spot. 

File Size And Startup Cost

Keen eyes will notice something about the above screenshot. The file size. It’s over 70MB! That’s crazy for an application that does nothing but print Hello World to the screen! This is solved in Preview 6 of .NET Core 3.0 with a feature called IL Linker or Publish trimmer that omits DLL’s that aren’t used. You can read more about that here!

The other issue you may find is that there is a slight startup cost when running the self contained executable for the first time. Because it needs to essentially unzip all dependencies to a temporary directory on first run, that’s going to take a little bit of time to complete. It’s not crazy (5 seconds or so), but it’s noticeable. Luckily on subsequent runs it uses this already unzipped temp folder and so startup is immediate.

Dec 14, 2016.

That’s the date I registered A week later I would register because I was worried someone would just chop off the “s” from the end and copy me.

Almost 3 years later and I have seen some crazy things with this platform. The “poopooing” of the project.json format, the deprecation then un-deprecation of ASP.NET Core running on full framework, and now the introduction of desktop apps to run on .NET Core.

Through all of that, I get a steady stream of emails asking for help on projects. It goes from individuals asking me to take a squiz at their github projects and point out glaring mistakes, all the way to large corporates getting me to build a migration plan on how they can get their existing .NET Framework project onto .NET Core. So that’s why I’m…

“Opening up the consultancy”

That’s probably a bit of an over the top statement. But it’s more like I’ve updated a couple of pages on the website to make it clear that there is no harm in reaching out and seeing how we can work together. I try and reply to each and every email even if I can’t be of too much help at the time.

So go ahead, contact me and get your .NET Core project moving today!

A Word On Product Posts

While not strictly related to consulting. I did want to mention “product posts” that sometimes pop up here from time to time. These might be posts on hosting platforms, dev tooling, monitoring solutions, or any other “paid” product used in software development.

I at times get emails from companies looking to promote their new tool, and they want me to do a nice write up on how amazing it is. But…

  • If I personally would not use the product, I do not write about it.
  • If I think the product is overpriced, I do not write about it.
  • If I feel that there is a snake oil element to the product (misleading landing pages, promises etc), I do not write about it.

Very few products make it past this line, and therefore ones that I do write about are ones that I actually use myself. This does mean that the majority of requests I get to write posts do not actually make it onto the blog, but I think it’s important that readers trust that when I write about the product, it’s worth their money.

So with all that being said, I just want to make it clear that yes, sometimes companies contact me asking to write about their product. But if I do write about it, it’s my own words with my own personal experience with the tool.

With that out of the way, if you have a product used in software development you think would benefit readers, you can contact me here.

.NET Core 3.0 Preview 6 has been released as of June 12th. You can grab it here :

What’s Included

The official blog post from Microsoft is here : . But of course if you want the cliff notes then…

Docker Images For ARM64

Previously docker images for .NET Core were only available for X64 systems, however you can now grab ’em for ARM64 too!

Ready To Run Images

Probably the most interesting thing contained in this release is the “Ready To Run” compilation ability. If you’ve ever used NGEN in previous versions of the .NET Framework, or attempted to some ahead of time jitting to improve your applications startup performance, then this is for you.

Better Assembly Linking

It’s always been possible to publish self contained applications in .NET Core that don’t require the runtime to be present on the destination machine. Unfortunately this sometimes made self contained apps (even one’s that did nothing but print Hello World!) become massive. Preview 6 contains a way to trim the required assemblies to reduce the footprint by almost half.

HTTP/2 Support In HTTPClient

HTTP/2 support has reached .NET Core! The default is still HTTP/1.1, but you are now able to opt in to create connections using a specific version. HTTP/2 opens up the world of multiplexed streams, header compression and better pipelining.

Worth Updating?

Probably the biggest thing for most developers in this version is HTTP/2 support. It’s likely something that will become defacto in the future so if you want to get ahead of the curve, get stuck in!

Ready To Run images are also pretty huge. If you remember that famous blog post from the Bing team around performance improvements they gained from switching to .NET Core 2.1 (, a big factor was ahead of time compiling of the code. So it’s definitely going to change the game for a lot of companies running .NET Core code.