I recently had the opportunity to log a bug against Entity Framework Core on Github with the Microsoft team. Before I sent it through, I took a look at other issues listed against the project to see the best way to describe my problem in such a public forum. While some reports were really detailed and got right to the heart of the issue, others were really weak and were likely better off being StackOverflow questions. Sometimes the reports actually did sound like they could be bugs, but just had absolutely no detail in them to take any further. Sometimes the user just didn’t quite know how to articulate the issue, and instead of outlaying the problem via code (We are developers after all), they just gave a wall of text to try and describe the problem they were having.

With that in mind, I thought I would jot down my top 3 things I noticed these poor bug reports were lacking. While I used the EF Core project on Github as examples, I didn’t

Debug It Yourself

A simple thing, but something that didn’t look like it was happening as much as it should. The amount of code that I use in day to day work that is open source is actually astounding to think about when compared to just a few years ago. With that in mind, everytime I start getting weird exceptions that I think could be a bug, I immediately go and check if I am able to get my hands on the source code to have a look.

I think sometimes people have a fear that the code will be way over their heads and difficult to understand. But it can be as simple as searching an open source project for the exception message or error code you are getting.

Let’s take my bug for example. It related to an exception being thrown from Automapper with very specific wording. Literally all I did was try and do a search on Github for the exact error message  and what do you know!

Digging deeper we can see the following lines of code :

private const string AlreadyInitialized = "Mapper already initialized. You must call Initialize once per application domain/process.";

...

public static IConfigurationProvider Configuration
{
	get => _configuration ?? throw new InvalidOperationException(InvalidOperationMessage);
	private set => _configuration = (_configuration == null) ? value : throw new InvalidOperationException(AlreadyInitialized);
}

OK so that’s given us a pretty good idea that the configuration is being set twice for some reason. It sets our brain in motion for different ways we could test theories about why this would be happening. As it turned out, it’s because a particular method in .NET Core runs twice when it should only be running once. And the reason it only happened in particular with Automapper was because the variable itself is static in the Automapper code (Another thing we learned by taking a look at the source ourselves).

We may not be able to completely code a fix, but will atleast help us to better articulate the issue and come up with simple repo steps when we log our bug report.

Don’t forget to explain what you’ve already looked into or done when logging the issue too. I saw a couple of bugs logged that had quite a bit of back and forth along the lines of “Can you try doing this?”, and the reply being “Yes, I have already tried that”. Well then put it in the report!

Create A Complete Solution Repository

Many reports start off with “Create a web project, then add this nuget package with this particular version, and then write code that does XYZ, then …”. It quickly becomes hard to follow and actually ends up with some sort of miscommunication issue anyway.

Creating a minimal code solution in it’s repository serves two purposes. The first is that you no longer have to explain exactly how someone can replicate the issue. The second is that it actually helps you remove any possible issues with your own code. Isolating the bug to it’s simplest possible form in a nice stand alone application is one of the biggest things you can do to help move a bug report along quickly.

And remember, it doesn’t have to be some amazing engineering feat. The Github repository I submitted with my bug report can be found here. It’s literally the Web API standard project template (Complete with the default routes and controllers), with a couple of extra lines in my startup file to replicate the bug. It may seem like going to this effort to upload what is almost a default project is a big hassle, but if you don’t, then the developer looking into your bug will have to do it anyway.

Simplify The Issue To As Few Code Lines As Possible

And finally, while you may have created a repository replicating the issue, it’s still a good idea to be able to reduce the bug down to as few lines of code as possible and have this code sitting in the bug report itself. Even pseudocode is better than nothing.

Let’s try something. I’ll explain a fictitious bug first in words, then in code.

Bug explanation in words :
When I run a select on a list that contains a cast, then call first on the return list, I get an error. If I don’t cast in the select (But still run the select) on the list, then call First, I don’t get an error.

Bug explanation in code :

myList.Select(x => x).First(); //No exception thrown
myList.Select(x => (string)x).First(); //Exception thrown

Which one is easier to follow for you? If you’re a developer, I can almost guarantee that looking at code is easier for you. When we’ve spent years looking at lines of code on our screen, it just *clicks* in our brain when we see it there.

Now that doesn’t mean that you shouldn’t also write a concise description of your bug too! That’s still important. And the same can be said for creating an entire solution to replicate your issue. Pasting lines of code into a bug report supplements your reproducible solution, it doesn’t replace it.

Summary

There’s a tonne of nuances around logging bugs for open source projects. Especially when the projects are as big as some of the Microsoft ones are. I could go on and on with other smaller issues that seemed to stall bug reports, but to me these were the big 3 that almost all bugs that got thrown back over the fence were lacking. What’s your tips for a good bug report? Drop a comment below and let us know.

The web has been going ballistic over a proposed ASP.net Core change.

Exhibit A : https://github.com/aspnet/Home/issues/2022

ASP.net Core was now going to run solely on…. .net core. Sounds confusing? Keep reading.

It’s been interesting to read reaction on message boards such as Reddit and HN. Mostly because people take the opportunity to lay the smack down on Microsoft without full understanding the situation. Certainly if you don’t use .net core on a daily basis, it just looks like Microsoft doing whatever it wants developers be damned.

But here’s the thing. I actually agree with Microsoft on this one to a certain degree. And I actually think their eventual decision to not press forward with the changes could actually hurt ASP.net core in the long run. This post is a bit of a riff off a Reddit comment I also made so it may be a bit over the place.

Let me explain.

There is currently 3 (main) ways to write a web application in the .net ecosystem

• ASP.net Core
• ASP.net Full Framework
• ASP.net Core running on Full Framework

That last one is probably the eye brow raiser and the one that sounds the most “cobbled together”. And it’s actually the one that everyone is fighting over.

You see you can actually run ASP.net Core on the full framework. You get all the benefits that the ASP.net Core team gives you (Kestrel etc), but you still have the ability to use full framework libraries. Sounds like a win win right? Kinda.

The reason this works is because ASP.net Core is written against .net standard. That means any classes/methods it calls will also be available in full framework. But it also limits the ability for ASP.net Core to innovate. They are restricting their own platform to keep the ability of running on the full framework.

So how does the .net standard work? There is another article on this site talking about the standard in general over here, but I’ll do my best to explain it in the context of the ASP.net Core 2.0 debacle.

.net standard is essentially an agreement between the various .net platforms (UWP, .net Full Framework, .net Core, Mono etc), that they will all implement the same functionality. Think of it like an interface where a class can write an implementation of a method however they like, but the important thing is that they implement it in the first place. The issue with the standard as it is today is that everyone has to move together. If the .net core team says “OK, we would like this new thing in the standard please”, they have to wait for agreement from another platform to put it into the standard and implement on their end too (Usually this is going to be from the full framework team).

The problem that the ASP.net core team is facing right now is that they have almost zero baggage and can move at an extreme pace. They are able to innovate and throw things into their platform as fast as a developer can code really. That’s why people are using ASP.net core running on full framework, because they are enjoying the performance improvements that ASP.net core offers. But for them to keep improving AND for ASP.net core to keep supporting the ability to run on full framework, they need the full framework to add things almost as fast so that new versions of the .net standard can be released.

That’s not happening.

And what that means is that if ASP.net Core writes a new feature that utilizes something that is NOT in the .net standard at that point, they cannot actually release it until the .net framework catches up. The ASP.net Core team has basically said that for them to keep moving at the same pace, they are going to have to make their libraries work on .net core only so that their only limitation to releasing new features is their own ability to write them.

To me that’s understandable. They probably need some sort of pathway for those that have been caught in the middle of this hybrid approach. But we can’t have a web framework that everyone loves for it’s ability to innovate be tied down by a legacy frameworks ability to do the same.

Microsoft has backtracked and said that they will continue supporting ASP.net core running on the full .net framework. I think it will be interesting a year from now to see how this pans out. Giving something like another years support seems look a good plan, but I don’t like the open ended support “we will see in a year” type approach.

What’s your thoughts?

Microsoft has released an urgent patch to various packages in .net core. If you are using any of the following packages directly, or any packages you use are also dependent on these packages you should update them immediately. You can read the full advisory on Github here.

Fixing Direct Dependencies

To fix direct dependencies, you should simply open your csproj file for your project and check package references for the ones above. If you find any, then you should update to the fixed package version and redeploy immediately if your project is in production.

For example if you had the following csproj file :

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp1.1</TargetFramework>
  </PropertyGroup>
  <PropertyGroup>
    <PackageTargetFallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</PackageTargetFallback>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore" Version="1.0.3" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0 " />
  </ItemGroup>
</Project>

The package for Microsoft.AspNetCore version 1.0.3 is vulnerable. Update the version to 1.0.4.

Fixing Transitive Dependencies

Transitive dependencies are dependencies of libraries that you are directly using. These are harder to track down but still simple to fix.

Open your project.assets.json file for your project (Should be in your project folder). Search inside this file for any dependencies that match the vulnerable package list above. If you find a vulnerable package, you need to manually add a reference to the fixed package in your csproj. The csproj version will override any transitive dependencies from other libraries (think of it like version forwarding in web.configs).

Fixing Project.Json (Legacy .net Core Apps)

If you have a .net core web app that is still on project.json, the process is much the same. For more info read the full advisory on Github here.

Microsoft have released a security advisory warning that there is a vulnerability in ASP.net core 1.1 MVC Core package that could allow a Denial Of Service attack. Exactly how to use the vulnerability is not being disclosed by Microsoft at this stage. Understandably so as it seems any .net core app that is on 1.1 will be affected. Note that any ASP.net core version below 1.1 is not affected.

Further info/discussion :

Github Announcement
Redhat Announcement
Reddit Discussion
HN Discussion

The issue is in a package named “Microsoft.AspNetCore.Mvc.Core”, but most people will find that they have a direct reference to the “parent” package named “Microsoft.AspNetCore.Mvc”. Either way, you need to do the below and patch.

How To Patch (project.json)

This is how to fix the vulnerability if you are using project.json (e.g. ASP.net Core 1.1 Preview 2). If you are using csproj (Preview 4), then check the section below.

First open up your project.json file and do a search for “Microsoft.AspNetCore.Mvc*”. So that includes any reference to sub packages such as “Microsoft.AspNetCore.Mvc.Core”. Let’s say you have a project.json similar to the below.

{
  "dependencies": {
    "Microsoft.NETCore.App": {
      "version": "1.1.0",
      "type": "platform"
    },
    "Microsoft.AspNetCore.Diagnostics": "1.1.0",
    "Microsoft.AspNetCore.Mvc": "1.1.0"
......
}

You need to bump the version of the MVC dependency. So change it to 1.1.1 like so :

{
  "dependencies": {
    "Microsoft.NETCore.App": {
      "version": "1.1.0",
      "type": "platform"
    },
    "Microsoft.AspNetCore.Diagnostics": "1.1.0",
    "Microsoft.AspNetCore.Mvc": "1.1.1"
......
}

Open a console inside your project folder and run “dotnet restore” and you should be now on the patched version of the library. Deploy your updated application as soon as possible.

If you cannot find a reference to “Microsoft.AspNetCore.Mvc*” in your project.json it does not mean you are immune.

Open your project.lock.json file, and search for “Microsoft.AspNetCore.Mvc.Core”. If you find it inside this file, it means that a package you are using has a dependency on the package. In this case, you need to manually add the full line to your project.json dependencies.

"Microsoft.AspNetCore.Mvc.Core": "1.1.1"

How To Patch (.csproj)

Patching your csproj file is almost identical, but in lovely XML form.

Search for a reference to “Microsoft.AspNetCore.Mvc*”. It will look something like below :

<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.0" />

Bump the version number by 1 :

<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.1" />

Open a command prompt in your project folder and run “dotnet restore”. Deploy your updated application as soon as possible.

If you cannot find a reference to “Microsoft.AspNetCore.Mvc*” in your project.json it does not mean you are immune.

You should find a file named project.assets.json in your project folder. Open this and search for “Microsoft.AspNetCore.Mvc.Core”. If you find it, it means that a package you are directly using has a reference itself to the MVC Core package. You need to open up your .csproj, and add in the following line :

<PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="1.1.1" />

Open up a command prompt in your project folder and run “dotnet restore” and you are done. Deploy your updated application as soon as possible.

It’s hard to read an intro to .NET Core without someone also introducing .NET Standard and then quickly moving on, leaving you to wonder just what is the .NET Standard. I’ve seen the same questions come up over and over again.  Is it another framework I have to learn? Is it the old .NET? Is .NET Standard and .NET Core the same? Hopefully we can answer all those questions today!

.NET Standard Is Exactly That. A Standard.

.NET Standard is for lack of a better word, a standard. It’s a description of the core interfaces that every .NET platform should implement if they wish to say “I support .NET Standard 2.0” for example.

An easy way to see what exactly the standard defines is actually the nuget package here : https://www.nuget.org/packages/NETStandard.Library . If you scroll down you will see descriptions of what each standard defines. So for example, .NET Standard 1.1 introduces System.Linq. If you would like to use System.Linq, you will need to use a platform that implements .NET Standard 1.1.

That brings us to the next point….

What Is A Platform?

It’s may be also good to take a step back and look at what exactly is a platform. At the moment the Microsoft .NET platform list looks like.NET Framework (Old .NET), .NET Core, Xamarin, Universal Windows Platform (UWP), Windows Phone and now also Mono.

Each platform version will implement a specific .NET Standard version. So for example, .NET Framework Version 4.6 implements the .NET Standard 1.3, whereas .NET Core Version 1.0 implements .NET Standard 1.6. If I were to write a library that I wanted a developer to use in both .NET Framework Version 4.6 and .NET Core Version 1.0, then I would have to target the lowest .NET Standard that these platforms implement. That being .NET Standard 1.3 in this case.

Microsoft have released an easy to view “chart” that tells you which version of each platform implements each version of the standard. You can see it here.

It’s important to note that each platform can implement it’s own features. Windows Phone for example may implement phone specific classes and interfaces, but it will also expose a classes and interfaces of it’s corresponding .NET Standard.

When Do You Have To Worry About It?

If you are writing for a particular platform, you usually don’t have to worry about .NET Standard at all. You may at times wish to look up the standard to see what would be coming to your platform next release, but that’s about it.

If you are developing your own library that you wish to be used across multiple platforms, that’s when the .NET Standard comes in handy. If you write a library that you want working on .NET Core, UWP, Windows Phone and .NET Framework, you will need to only use classes that are available on all of those platforms. How do you know what classes are available on all platforms? The .NET Standard!

What we will likely see in the future from library developers is the requirements changing from “You need .NET Framework version 4.6” to, “This is built on top of .NET Standard 1.6”. And from there you can go and look up what platforms use that standard.

A Web Analogy

Let’s try and think about this in a web sense. It’s not a direct analogy, but we’ll try. Let’s take ECMAScript or Javascript as an example. ECMAScript is a standard. It’s defined in a way that browsers then have to implement. Each browser implements ECMAScript, but they can also do their own things on top (In terms of favourites, addons, plugins etc). This is similar to how a .NET platform would work, they implement the standard, but then they can add their own platform specific items on top.

Now if you are writing a website and you wish to use a certain feature of javascript, you have to look at what browsers have implemented that feature. Then you make the decision, either you support “old” browsers, or you only outlay your support for certain modern browsers. This is similar to how it would work if you were writing a .NET library. You look at what platforms you wish to support, but if they are old, crusty and are only implementing an old version of the .NET Standard, then you can forgo supporting that platform and target a higher standard.

There is one big difference however. Unlike ECMAScript (And other web technologies like CSS), it’s hoped that platforms implement an all or nothing approach when it comes to moving up the .NET standard ladder. Either you implement .NET Standard 1.5 or 1.6, but you don’t release a platform version that implements 1.5 and a few features from 1.6. Remember, .NET Standard is supposed to make it “easy” to determine what classes and interfaces you have available.

Questions?

I’ll admit, I’m still wrapping my head around how .NET Standard works. But it’s early days yet. You can go to the Microsoft Github and see people still discussing how things should work long term, so it’s not just your everyday developer trying to work it out. If you have any questions feel free to comment below and I’ll do my best to answer.

So you’ve heard about ASP.net Core and you’re considering the move, but you want to know if it’s really worth it. You will always have to weigh up the pros and cons, especially if you are intending to move an existing app into .net core. But here’s 5 reasons you should definitely consider ASP.net core for your next project.

It’s A Small Learning Curve

Yes it’s true that there is a learning curve when learning .net core, even if you’re a seasoned ASP.net developer, but it’s not as big as you might think. For example, the language is still C#, namespaces are often the same or have been lifted and shifted to an easy location, and many classes/pieces of code you already have are usually able to be moved without too much hassle.

With that being said, there are a few notable exceptions. Things like cryptography services have either been severely changed. In some cases classes like the FTPWebRequest have been completely removed, much to the annoyance of some (Although should be added back in the future). If you are doing a small test application in .net core or have full embraced microservices, you will quickly be able to validate if .net core has everything you need. If you are attempting to port a massive monolith, it might be worthwhile researching into the few things .net core is currently lacking before setting off.

Multi Platform

Usually seen as the number one reason to make the switch. ASP.net Core is able to be run (And developed) on Windows, Mac and Linux. While Visual Studio is still Windows only, VS Code and Jetbrains Rider are available on all OS to develop .net core solutions. Your devops team will no doubt love you with the ability to now deploy the code on cheaper (And to some people, more reliable) Linux machines too!

It’s not like you are left on your own to work it out either. Microsoft has published documentation on getting ASP.net core running on Ubuntu, documentation on getting ASP.net core running on Apache with CentOS, and even how to get everything up and running on Docker. Imagine that happening just 5 years ago!

One Web Framework To Learn

In previous versions of ASP.net you had a difference between MVC controllers and API controllers. It seemed simple enough, but you then ended up with different ways to configure your web app. You could be half way through a ModelBinding tutorial before you realized it was for MVC only and you had to do something slightly different to get it working in the API. It was super frustrating! But in .net Core, It is all one and the same. One action can return JSON data, one can return an ActionResult, all in the same controller!

It’s Light

Previously you had to have the .net framework installed on your target machine when deploying. Not anymore! When deploying .net applications you can package up everything your app needs into a single zip and deploy only that. That means that your only shifting exactly what you need, as well as reducing the complexity of a machine setup if you are doing horizontal scaling.

It’s Fast

While the results are somewhat disputed on how “useful” and “real world” they are. The current benchmarks of ASP.net core’s web server (Kestrel), can currently serve over 1.2 million requests per second. For comparison in that benchmark, standard IIS can server around around 60k per second. These are plaintext benchmarks so it’s not running actual .net core code, but it’s still interesting to see the huge improvement in web server performance.