Roundup #4: Discover.NET, Signed Nuget Packages, Scheduled Messages in Jasper, RailsConf Keynote

Here are the things that caught my eye last week.  Throwing something out of my usual focus on .NET and tossing in the Railsconf keynote.  I generally pay attention to other ecosystems but just don;t really post it on this blog.  But I might start sneaking some in on the roundups.

I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.


Last week I was on vacation, hence the missed roundup.

Discover .NET

I am thrilled to announce the launch of Discover .NET. The site is an attempt to improve discoverability in the .NET ecosystem by collecting information on topics like projects, issues, blogs, groups, events, and resources.

What a awesome idea and really glad to see Dave take the time and effort to put this together.  I love this so much because ultimately this is my main goal for this blog and this series of posts.  To showcase some of the great people, libraries, tools, etc in ecosystem.


Signed package submissions to

In September 2017, we announced our plans to improve the security of the NuGet ecosystem by introducing the ability for package authors to sign packages. Today, we want to announce support for any user to submit signed packages to

As the post mentions, this really revolves around Package integrity and authenticity.  Glad to see this is now available.


Scheduled or Delayed Message Execution in Jasper

The scheduled messages can be processed by any of the running nodes within your system, but we take some steps to guarantee that only one node will execute specific scheduled messages. Rather than using any kind of leader election, Jasper just takes advantage of advisory locks in Postgresql or application locks in Sql Server as a lightweight, global lock between the running nodes within your application.

As mentioned at the top of the post, this isn’t a replacement per say for something like Hangfire completely, but does offer the ability to schedule message execution.  I’m likely going to be looking at Jasper a bit more in the future.



RailsConf 2018: Opening Keynote: FIXME by David Heinemeier Hansson

Found this to be a pretty interesting keynote.  Lower the barrier to entry, abstractions and complexity.  Worth a watch.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Migrating to .NET Core: NuGet Package Dependencies

There are a few road blocks from migrating to .NET Core.  One roadblock is .NET Framework API’s that are not included in NETStandard2.0.  Another, is NuGet Package dependencies.

I’ll cover the API surface in another post, but for this post I want to show you a couple quick ways you can check if your NuGet package dependencies are compatible with .NET Core.


If you head over to and search for the package you depend on, there you can click to expand the Dependencies heading which will list all the targets.  Here’s an example of the MediatR package.

You can see which Platforms and versions of .NET Standard it supports.  And for each target ,which dependencies it has under that target.

I Can has .NET Core

The folks at Octopus Deploy released  Here’s what how it works:

Upload your project’s packages.config, project.json, paket.dependencies and *.csproj files for analysis and we will build a visualization of the packages and whether .NET Standard versions are available on

Give it try to see which NuGet packages you consume that are targeting .NET Standard.

Another interesting feature on the site is the Statistics page which shows Unsported and Supported packages that have been scanned.  I really am amazed how many library authors picked up on and supported .NET Standard.

Dependency Roadblocks

If find yourself blocked from migrating to .NET Core because of dependencies on certain NuGet packages, I’d love to hear about which ones? Also, if you were blocked but found an alternative package, let me know in the comments section or on Twitter.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

EF Core: Logging Lazy Loading

Entity Framework Core: Logging Lazy LoadingIf you are planning on migrating from Entity Framework 6.x to Entity Framework Core, there is likely one major road block: Lazy Loading.

In most circumstances I don’t think lazy loading is a good idea.  If you were using Entity Framework, you may be using Lazy Loading unintentionally since it’s built in by default.

Eager Loading

To eager load a related entity, you specify the related entity to be populated with the Include() method.  This is applicable in EF and EF Core.  However in Entity Framework 6.x, if you do not Include() a related entity, and access that navigation property, but default it will be lazy loaded.

Meaning a SQL statement will occur to load the related entity.  If you are iterating over a collection, this is where the N+1 comes from.

I assume this is why Entity Framework Core held out until 2.1 before providing a way to lazy load related entities since it’s now an opt-in.


As mentioned, Entity Framework Core 2.1 now supports Lazy Loading as an opt-in.

I don’t recommend turning this on from a fresh project, but it may be applicable if you are migrating from Entity Framework 6.x to EF Core.   You can get pretty far with your existing LINQ queries without having to rewrite a large portion of your app.

Enable Lazy Loading

I don’t want to re-write the docs on how to enable Lazy Loading, so check them out.  However, I do want to show my preferred method and strategy that if you enable lazy loading, that you can log when it occurs.

This will provide you insights about where in your existing LINQ you are not calling Include() and eager loading the related entity.

First, to enable lazy loading, I’m going to add a param of Action<object, string> that will be injected into your entity by Entity Framework.  If the related entity being accessed is null, I’m going to Load the related entity, but also log out to the Console.  Obviously you would be using the logging tool you prefer, for this demo I’m just creating a console application.


Here’s a simple console application that first inserts a parent entity with two children. Then on the first call it does not Include() and will force lazy loading, which in turn will be logged to the console.  In the second call, Include() will be called and no lazy loading occurs.

Migration Comments

Have you migrated from Entity Framework 6.x to Entity Framework Core?  I’d love to hear about it in the comments or on Twitter.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.