Scott Hanselman

Free Training at Microsoft Virtual Academy - Introduction to ASP.NET 5

September 16, '15 Comments [23] Posted in ASP.NET | Learning .NET
Sponsored By

In 2013, Jon Galloway, Damian Edwards, and myself went up to film a LIVE 8 hour long Microsoft Virtual Academy training session called "Building Web Apps with ASP.NET Jump Start." We returned in 2014 with "Building Modern Web Apps with ASP.NET." Both of these are free, and are effectively a full day each of content.

Just a few weeks back here in September of 2015, we recorded "Introduction to ASP.NET 5." This is 100 to 200 level beginner content that starts at the beginning. If you're just getting started with ASP.NET 5 (currently in Beta) or perhaps you have been meaning to dig into the new stuff in ASP.NET 5 but haven't gotten around to it, this a good place to start.


Introduction to ASP.NET 5

We cover

  • Introduction to ASP.NET 5
  • Introduction to Visual Studio
  • Introducing Model View Controller (MVC6)
  • Getting Started with Models, Views, and Controllers
  • Debugging Web Applications
  • Configuration Data
  • Publishing Your Application
  • Using Data with Entity Framework

In the final three segments, we work with Damian Edwards to dissect every line of code in the real-world cloud-deployed application that runs our weekly standup at

  • Exploring
  • Managing Data on
  • Advanced Features in

It's a full day of detailed video training with assessments after each video. You can seek around, of course, or download the videos for offline viewing. We are pretty happy with how it turned out.

We'll be returning to Microsoft Virtual Academy over the next several months to record 300-400 level advanced content as well as a Cross-Platform specific show for Mac and Linux users who want to develop and deploy ASP.NET applications. I hope you enjoyed it, we all worked very hard on it.

Sponsor: Big thanks to my friends at Infragistics for sponsoring the feed this week! Responsive web design on any browser, any platform and any device with Infragistics jQuery/HTML5 Controls.  Get super-charged performance with the world’s fastest HTML5 Grid - Download for free now!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

Proper benchmarking to diagnose and solve a .NET serialization bottleneck

February 20, '15 Comments [25] Posted in ASP.NET | Learning .NET | Open Source
Sponsored By

From's a few comments and disclaimers to start with. First, benchmarks are challenging. They are challenging to measure, but the real issue is that often we forget WHY we are benchmarking something. We'll take a complex multi-machine financial system and suddenly we're hyper-focused on a bunch of serialization code that we're convinced is THE problem. "If I can fix this serialization by writing a 10,000 iteration for loop and getting it down to x milliseconds, it'll be SMOOOOOOTH sailing."

Second, this isn't a benchmarking blog post. Don't point this blog post and say "see! Library X is better than library Y! And .NET is better than Java!" Instead, consider this a cautionary tale, and a series of general guidelines. I'm just using this anecdote to illustrate these points.

  • Are you 100% sure what you're measuring?
  • Have you run a profiler like the Visual Studio profiler, ANTS, or dotTrace?
  • Are you considering warm-up time? Throwing out outliers? Are your results statistically significant?
  • Are the libraries you're using optimized for your use case? Are you sure what your use case is?

A bad benchmark

A reader sent me a email recently with concern of serialization in .NET. They had read some very old blog posts from 2009 about perf that included charts and graphs and did some tests of their own. They were seeing serialization times (of tens of thousands of items) over 700ms and sizes nearly 2 megs. The tests included serialization of their typical data structures in both C# and Java across a number of different serialization libraries and techniques. Techniques included their company's custom serialization, .NET binary DataContract serialization, as well as JSON.NET. One serialization format was small (1.8Ms for a large structure) and one was fast (94ms) but there was no clear winner. This reader was at their wit's end and had decided, more or less, that .NET must not be up for the task.

To me, this benchmark didn't smell right. It wasn't clear what was being measured. It wasn't clear if it was being accurately measured, but more specifically, the overarching conclusion of ".NET is slow" wasn't reasonable given the data.

Hm. So .NET can't serialize a few tens of thousands of data items quickly? I know it can.

Related Links: Create benchmarks and results that have value and Responsible benchmarking by @Kellabyte

I am no expert, but I poked around at this code.

First: Are we measuring correctly?

The tests were using DateTime.UtcNow which isn't advisable.

startTime = DateTime.UtcNow;
resultData = TestSerialization(foo);
endTime = DateTime.UtcNow;

Do not use DateTime.Now or DateTime.Utc for measuring things where any kind of precision matters. DateTime doesn't have enough precision and is said to be accurate only to 30ms.

DateTime represents a date and a time. It's not a high-precision timer or Stopwatch.

As Eric Lippert says:

In short, "what time is it?" and "how long did that take?" are completely different questions; don't use a tool designed to answer one question to answer the other.

And as Raymond Chen says:

"Precision is not the same as accuracy. Accuracy is how close you are to the correct answer; precision is how much resolution you have for that answer."

So, we will use a Stopwatch when you need a stopwatch. In fact, before I switch the sample to Stopwatch I was getting numbers in milliseconds like 90,106,103,165,94, and after Stopwatch the results were 99,94,95,95,94. There's much less jitter.

Stopwatch sw = new Stopwatch();

// stuff


You might also want to pin your process to a single CPU core if you're trying to get an accurate throughput measurement. While it shouldn't matter and Stopwatch is using the Win32 QueryPerformanceCounter internally (the source for the .NET Stopwatch Class is here) there were some issues on old systems when you'd start on one proc and stop on another.

// One Core
var p = Process.GetCurrentProcess();
p.ProcessorAffinity = (IntPtr)1;

If you don't use Stopwatch, look for a  simple and well-thought-of benchmarking library.

Second: Doing the math

In the code sample I was given, about 10 lines of code were the thing being measured, and 735 lines were the "harness" to collect and display the data from the benchmark. Perhaps you've seen things like this before? It's fair to say that the benchmark can get lost in the harness.

Have a listen to my recent podcast with Matt Warren on "Performance as a Feature" and consider Matt's performance blog and be sure to pick up Ben Watson's recent Book called "Writing High Performance .NET Code".

Also note that Matt is currently exploring creating a mini-benchmark harness on GitHub. Matt's system is rather promising and would have a [Benchmark] attribute within a test.

Considering using an existing harness for small benchmarks. One is SimpleSpeedTester from Yan Cui. It makes nice tables and does a lot of the tedious work for you. Here's a screenshot I stole borrowed from Yan's blog.


Something a bit more advanced to explore is HdrHistogram, a library "designed for recoding histograms of value measurements in latency and performance sensitive applications." It's also on GitHub and includes Java, C, and C# implementations.


And seriously. Use a profiler.

Third: Have you run a profiler?

Use the Visual Studio Profiler, or get a trial of the Redgate ANTS Performance Profiler or the JetBrains dotTrace profiler.

Where is our application spending its time? Surprise I think we've all seen people write complex benchmarks and poke at a black box rather than simply running a profiler.

Visual Studio Profiler

Aside: Are there newer/better/understood ways to solve this?

This is my opinion, but I think it's a decent one and there's numbers to back it up. Some of the .NET serialization code is pretty old, written in 2003 or 2005 and may not be taking advantage of new techniques or knowledge. Plus, it's rather flexible "make it work for everyone" code, as opposed to very narrowly purposed code.

People have different serialization needs. You can't serialize something as XML and expect it to be small and tight. You likely can't serialize a structure as JSON and expect it to be as fast as a packed binary serializer.

Measure your code, consider your requirements, and step back and consider all options.

Fourth: Newer .NET Serializers to Consider

Now that I have a sense of what's happening and how to measure the timing, it was clear these serializers didn't meet this reader's goals. Some of are old, as I mentioned, so what other newer more sophisticated options exist?

There's two really nice specialized serializers to watch. They are Jil from Kevin Montrose, and protobuf-net from Marc Gravell. Both are extraordinary libraries, and protobuf-net's breadth of target framework scope and build system are a joy to behold. There are also other impressive serializers in including support for not only JSON, but also JSV and CSV in ServiceStack.NET.

Protobuf-net - protocol buffers for .NET

Protocol buffers are a data structure format from Google, and protobuf-net is a high performance .NET implementation of protocol buffers. Think if it like XML but smaller and faster. It also can serialize cross language. From their site:

Protocol buffers have many advantages over XML for serializing structured data. Protocol buffers:

  • are simpler
  • are 3 to 10 times smaller
  • are 20 to 100 times faster
  • are less ambiguous
  • generate data access classes that are easier to use programmatically

It was easy to add. There's lots of options and ways to decorate your data structures but in essence:

var r = ProtoBuf.Serializer.Deserialize<List<DataItem>>(memInStream);

The numbers I got with protobuf-net were exceptional and in this case packed the data tightly and quickly, taking just 49ms.

JIL - Json Serializer for .NET using Sigil

Jil s a Json serializer that is less flexible than and makes those small sacrifices in the name of raw speed. From their site:

Flexibility and "nice to have" features are explicitly discounted in the pursuit of speed.

It's also worth pointing out that some serializers work over the whole string in memory, while others like Json.NET and DataContractSerializer work over a stream. That means you'll want to consider the size of what you're serializing when choosing a library.

Jil is impressive in a number of ways but particularly in that it dynamically emits a custom serializer (much like the XmlSerializers of old)

Jil is trivial to use. It just worked. I plugged it in to this sample and it took my basic serialization times to 84ms.

result = Jil.JSON.Deserialize<Foo>(jsonData);

Conclusion: There's the thing about benchmarks. It depends.

What are you measuring? Why are you measuring it? Does the technique you're using handle your use case? Are you serializing one large object or thousands of small ones?

James Newton-King made this excellent point to me:

"[There's a] meta-problem around benchmarking. Micro-optimization and caring about performance when it doesn't matter is something devs are guilty of. Documentation, developer productivity, and flexibility are more important than a 100th of a millisecond."

In fact, James pointed out this old (but recently fixed) ASP.NET bug on Twitter. It's a performance bug that is significant, but was totally overshadowed by the time spent on the network.

Thanks to Marc Gravell and James Newton-King for their time helping with this post.

What are your benchmarking tips and tricks? Sound off in the comments!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

The .NET CoreCLR is now open source, so I ran the GitHub repo through Microsoft Power BI

February 4, '15 Comments [35] Posted in Azure | Learning .NET | Open Source
Sponsored By

The hits keep on coming, Dear Reader. Just as we announced a few months back, .NET Core is open source. We said it would run on Windows, Mac, and Linux, but then the work of doing it has to actually happen. ;)

Go check out the .NET Framework Blog. Today the .NET team put the Core CLR up on GitHub. It's open source and it's under the MIT License. This includes the Core CLR source, the new RyuJIT, the .NET GC, native interop and everything you need to fork, clone, and build your own personal copy of the .NET Core CLR. What a cool day, and what an immense amount of work (both technical and legal) to make it happen. Years in the making, but still lots of work to do.

The GitHub repo has 2.6ish MILLION lines of code. They say when it's all said and done.NET Core will be about 5 MILLION lines of open source code.

The .NET Blog did a nice pie chart, but honestly, I found it to be not enough. It basically was a big grey circle that said "other 2.2M." ;)

I'd like a little more insight, but I don't know if I have the compute power, or the patience, frankly, to analyze this code repository. Or do I?

I decided to import the repository into Microsoft Power BI preview. Power BI (BI means "Business Intelligence") is an amazing service that you can use (usually for FREE, depending on your data source) to pull in huge amounts of data and ask questions of that data. Watch for a great video on this at this week or next.

I logged into (It's US only for the preview, sorry) and clicked Get Data. I then selected GitHub as the source of my data and authorized Power BI to talk to GitHub on my behalf. Crazy, AMIRITE?

Screenshot (10)

After a few minutes of data chewing, I'm officially adding "BI and Big Data Analyst" to my resume and you can't stop me. ;)

What does Power BI tell me about the .NET Team's "CoreCLR" GitHub repository?

Here's what Power BI told me.


Let's dig in. Looks like Stephen Toub has worked on a LOT of this code. He's super brilliant and very nice, BTW.


Editing the query and looking at Dates and Times, it seems the .NET Team commits code at ALL hours. They are really feeling "committable" around 3 to 4 pm, but they'll even put code in at 4 in the morning!


Here's a more intense way to look at it.


One of the insanely cool things about Power BI is the ability to ask your data questions in plain English. Given that my SQL abilities have atrophied to "Select * from LittleBobbyTables" this is particularly useful to me.

I asked it "issues that are open sorted by date" and you'll notice that not only did it work, but it showed me what I meant underneath my query.


What about issues closed by a certain person?


I'm running around in this tool just building charts and asking questions of the repo. It's all in HTML5 but it's just like Excel. It's amazing.


Open issues from last year?


Average time to close an issue in hours?


It's amazing to be running queries like this on something as significant as the now open-sourced .NET Core CLR. I didn't need to be an employee to do it. I didn't need special access, I just did it. I'm enjoying this new Microsoft, and very much digging Power BI. Next I'm going to put my Blood Sugar and Diabetes Data in Power PI and encourage others to do the same.

P.S. Check out the code for the Core CLR Hello World app. When was the last time you saw an ASCII Art Linux Penguin in Microsoft Source code? ;)

Sponsor: Big thanks to Infragistics for sponsoring the feed this week! Responsive web design on any browser, any platform and any device with Infragistics jQuery/HTML5 Controls.  Get super-charged performance with the world’s fastest HTML5 Grid – Download for free now!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

Getting ready for the future with the Microsoft .NET Portability Analyzer

December 3, '14 Comments [10] Posted in Learning .NET
Sponsored By

.NET has been getting more and more portable. Not only is .NET Open Source going forward (read Announcing .NET 2015 - .NET as Open Source, .NET on Mac and Linux, and Visual Studio Community) but you of course know about Xamarin tools, as well as, I hope, the .NET Microframework, and much more.

You can run your .NET code all over, and there's a tool to make this even easier. While you'll rarely get 100% portable code with any platform, you can get into the magic 90-95% with smart refactoring, then keep the platform-specific shims pluggable.

The .NET Portability Analyzer is a free Visual Studio Add-in (or console app) that will give you a detailed report on how portable your code is. Then you can get a real sense of how far you can take your code, as well as how prepared you'll be for the Core CLR and alternate platforms.

.NET Portability

Take a look at this report on AutoFac, for example. You can see that the main assembly is in fantastic shape across most platforms. Understandably the more platform-specific Configuration assembly fares worse, but still there's a complete list of what methods are available on what platforms, and a clear way forward.

.NET Portability Report

You'll get suggestions with a direction to head when you bump up against a missing or not-recommended API.


You can analyze specific assemblies, or an entire project. Once installed, you'll find the commands under the Analyze menu, and you can change options in the .NET Portability Analyzer options in the Tools | Options menu.

Even better, you can use this with the FREE Visual Studio Community that you can download at

Related Links

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

Building a working Robot controlled by a C#, an iPhone, and Monkey.Robotics

October 28, '14 Comments [24] Posted in Learning .NET | Open Source
Sponsored By

Robot_TinyThis year at Xamarin's Evolve there was a Robot Building area that introduced a new beta platform called Monkey.Robotics (GitHub). There is a disclaimer on the GitHub: "Monkey.Robotics is still a beta/work in progress and is not officially supported by Xamarin" but I can say that I was able to successfully build this robot with my 6 year old and we've had a blast driving it around the house! He was thrilled to solder (but not too much) and setup all the wires on the breadboard.

This robot is a great showcase for the larger Monkey.Robotics stack PLUS a great way to learn how to use Xamarin tools AND the .NET Micro Framework. And the end you'll have not just a robot with code running on a Netduino, but also have deployed C# code using Xamarin onto (in my case) an iPhone.

The resulting stuff you get to build and use are:

  • iPhone/Android app using Xamarin.Forms and controls or a gyroscope talking over your phone's Bluetooth radio to some code running on an...
  • Netduino running the open source .NET Micro Framework. This Netduino will receive communications via a Bluetooth radio on a chip. This BT LE board is connected to the GPIO (general purpose input output) pins on the Netduino. The board then controls...
  • Motors and wheels on a nice base, powered by 4 AA batteries.

The authors are some of my favorite people, including Bryan Costanich, Frank Krueger, Craig Dunn, David Karlas, and Oleg Rakhmatulin.

There's a deceptively large amount of code here and it's whole job is to hide the yucky parts of a project that connects mobile devices to wearables, sensors, peripherals, and low-level communication. They include a cross-platform API for talking with BLE (Bluetooth Low-Energy) devices, as well as the beginnings of a similar API over Wifi. Even more important is a higher level messaging framework sitting on top of these lower=level APIs. The net result is that talking Bluetooth between your phone and a device isn't very hard.

On the device side (in my case with .NET Micro Framework) they make things more compose-able with "blocks and scopes" style abstractions, allowing one to fairly easily connect output pins (LEDs, motors) to input pins (buttons, sensors).

Here is one of their basic examples. This makes an LED blink when a button is pressed.

public class Program
static H.Cpu.Pin buttonHardware = Pins.ONBOARD_BTN;
static H.Cpu.Pin ledHardware = Pins.ONBOARD_LED;

public static void Main()
var button = new DigitalInputPin (buttonHardware);
var led = new DigitalOutputPin (ledHardware);

button.Output.ConnectTo (led.Input);

// keep the program alive
while (true) {
System.Threading.Thread.Sleep (1000);

I went through the very excellent Project Walkthrough on building a Robot. Note that all this is on GitHub so if you have any issues, you can fix them and submit a pull request. I'm sure the project would appreciate it!


Here's what you need to buy/or have (I took from their GitHub site) if you want to build this same robot.

  • bot Chassis w/Motors - Just about any 2 wheeled robot chassis with motors and gears will work, but we like these. They're only $11 and they work well. Spark Fun also makes a similar robot chassis for $15, but the battery holder is difficult to access, otherwise, it's also very nice.
  • Netduino 2 - From Secret Labs, the Netduino is a programmable micro controller that runs the .NET Micro Framework.
  • BLE Mini - From Redbear Labs. Used to communicate with the robot from Xamarin.iOS and Xamarin.Android.
  • 400 Point Breadboard - The breadboard is where our electronics will all get connected. It has holes in it to put chips, sensors, wires, etc., into.
  • Breadboard Wiring Kit - Any wiring kit will work, but we especially like these. You may also want to get some male-to-male flexible jumper wires.
  • Dual H-Bridge Chip - Used to power the motors, H-bridges are simple chips that allow you to control motors with external power, so you don't burn out your Netduino trying to drive them with that. :) You can also build an H-bridge with some simple components, but buying a chip is easier and will likely cost about the same.
  • iOS or Android Device w/BLE Support - If using an iOS device, you'll need an iPhone 4 or later. If using an Android Device, you'll want to make sure that it has BLE support and is running at least Android v4.3.

Make sure you have you development and build environment setup, and then follow the guides below to get this thing up and running!

Basically you'll need Xamarin Studio or Visual Studio with Xamarin Tools. You'll also need the .NET Micro Framework bits, which are free for Visual Studio 2013, as well as the Netduino 4.3.1 SDK. There's a thread over at the Netduino Forums if you have trouble getting your device ready. I had no issues at all.

The Robot code is in a larger solution called Robotroller that's pretty nicely factored. You've got the Core functionality for the phone and the Core for the Robot.

The Phone code makes great use of databinding. The Car code is a little messy (it's beta and looks like Tests that turned into a working Robot! ) but it worked out of the box! It's surprisingly simple, in fact, due to the next abstraction layer provided by Monkey.Robotics.

How cool is this. That's basically it. Love it.

public class TestRCCar
public static void Run ()
// initialize the serial port for COM1 (using D0 & D1)
// initialize the serial port for COM3 (using D7 & D8)
var serialPort = new SerialPort (SerialPorts.COM3, 57600, Parity.None, 8, StopBits.One);
serialPort.Open ();
var server = new ControlServer (serialPort);

// Just some diagnostic stuff
var uptimeVar = server.RegisterVariable ("Uptime (s)", 0);

var lv = false;
var led = new Microsoft.SPOT.Hardware.OutputPort (Pins.ONBOARD_LED, lv);

// Make the robot
var leftMotor = HBridgeMotor.CreateForNetduino (PWMChannels.PWM_PIN_D3, Pins.GPIO_PIN_D1, Pins.GPIO_PIN_D2);
var rightMotor = HBridgeMotor.CreateForNetduino (PWMChannels.PWM_PIN_D6, Pins.GPIO_PIN_D4, Pins.GPIO_PIN_D5);

var robot = new TwoWheeledRobot (leftMotor, rightMotor);

// Expose some variables to control it
robot.SpeedInput.ConnectTo (server, writeable: true, name: "Speed");
robot.DirectionInput.ConnectTo (server, writeable: true, name: "Turn");

leftMotor.SpeedInput.ConnectTo (server);
rightMotor.SpeedInput.ConnectTo (server);

// Show diagnostics
for (var i = 0; true; i++) {
uptimeVar.Value = i;

led.Write (lv);
lv = !lv;
Thread.Sleep (1000);

Here's a video (don't play it too loud, my kids are yelling in the background) of me controlling the robot using my iPhone. Note I'm using the gyroscope control so I twist my hand to steer.

Robot via iPhone over BT LE. It's @Xamarin on phone plus @SecretLabs and @Xamarin on robot!

A video posted by Scott Hanselman (@shanselman) on

All in all, I'm enjoying Monkey.Robotics and I hope it takes off with more projects, more ideas, more things to build. If you've got interest or expertise in this area, go star their project and get involved! There's a LOT of stuff going on over there, so explore all the docs and diagrams.

Sponsor: Big thanks to my friends at Octopus Deploy. They are the deployment secret that everyone is talking about. Using NuGet and powerful conventions, Octopus Deploy makes it easy to automate releases of ASP.NET applications and Windows Services. Say goodbye to remote desktop and start automating today!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web
Page 1 of 31 in the Learning .NET category Next Page

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.