The .NET Stacks #14: Checking in on NuGet changes, many-to-many in EF Core, community roundup, and more!

We discuss many-to-many in EF Core 5, check in with upcoming NuGet changes, and look at the busy week in the .NET community!

Dave Brock
Dave Brock

Happy Monday. Do you ever watch a satire and think it’s a documentary?

This week, we’ll:

  • Get excited about many-to-many in EF Core
  • Take a look at some current and upcoming NuGet changes
  • Check in on the community

Many-to-many in EF Core 5

So this is exciting: many-to-many support is now included in the Entity Framework Core daily builds, and the team spent this week’s community standup showing it off.

A big part of this work includes the concept of skip navigations, or many-to-many navigation properties. For example, here’s a basic model that assigns links in a newsletter (what can I say, it’s fresh on my mind) and is a good use case for many-to-many and is … heavily inspired and/or outright stolen from the GitHub issue:

public class Link
{
    public int LinkId { get; set; }
    public string Url { get; set; }
    public string Description { get; set; }

    public List<LinkTag> LinkTags { get; set; }
}

public class Tag
{
    public string TagId { get; set; }
    public string Description { get; set; }

    public List<LinkTag> LinkTags { get; set; }
}

public class LinkTag
{
    public int LinkId { get; set; }
    public Link Link { get; set; }

    public string TagId { get; set; }
    public Tag Tag { get; set; }

    public DateTime LinkCreated { get; set; }
}

So, to load a link and its tags, I’d need to use two navigation properties, and refer to the joining table when performing queries:

var linksAndTags
    = context.Links
        .Include(e => e.LinkTags)
        .ThenInclude(e => e.Tag)
        .ToList();

With many-to-many in EF Core 5, I can skip over the join table and use direct navigation properties. We can instead get a little more direct:

public class Link
{
    public int LinkId { get; set; }
    public string Description { get; set; }

    public List<Tag> Tags { get; set; } // Skips right to Tag
    public List<LinkTag> LinkTags { get; set; }
}

public class Tag
{
    public string TagId { get; set; }
    public string Description { get; set; }

    public List<Link> Links { get; set; } // Skips right to Link
    public List<LinkTag> LinkTags { get; set; }
}

Look how easy querying is now:

var linksAndTags 
    = context.Links
        .Include(e => e.Tags)
        .ToList();

In the standup, Arthur Vickers mentioned an important fact that’s easy to overlook: while the release timing is similar, EF Core 5 is not bound to .NET 5. It targets .NET Standard 2.1, so can be used in any .NET Core 3.x apps (and of course is available for use in .NET 5). Take a look at the docs to learn more about .NET Standard compatibility.

Checking in on NuGet changes

This week, the .NET Tooling community standup brought in the NuGet team to talk about what they’re working on. They mentioned three key things: UX enhancements to nuget.org, improvements to package compatibility in Visual Studio, and better README support for package authors.

The team has been working on improving the experience on nuget.org—in the last few weeks, they’ve blogged about how you can use advanced search and also view dependent packages. While I prefer to work with packages in my IDE, you can hit up nuget.org for a better view, but it’s hard to filter through the noise. The new filtering options are a welcome improvement: I can filter by dependencies, tools, templates, relevance, downloads, and prereleases. Whether I value stability or finding out what’s new, the experience is a lot better now.

I was most interested to hear about tooling support, as that’s how a lot of us use NuGet most. The team discussed upcoming changes to floating version support. Floating version support means you’re using the latest version of a range you specify: for example, if you say you want version 2.* of a package, and it rolled out 1.0, 2.0, and 2.1 versions, you’re using 2.1. Soon, you’ll be able to specify this in the Version field in the NuGet UI—preventing you from hacking away from the project file. As a whole, the Version field will allow more flexibility and not just be a drop-down.

Lastly, if you author NuGet packages, README links will no longer be a post-package upload but built right into the Visual Studio Package Properties. That will allow you to easily have your package documentation on nuget.org, and the NuGet UI in Visual Studio will have a link to it.

🌎 Last week in the .NET world

🔥 The Top 3

📢 Announcements

📅 Community and events

😎 Blazor

Jon Hilton compares Blazor and Vue, and also works with client-side Blazor.

🚀 .NET Core

⛅ The cloud

📔 Languages

🔧 Tools

📱 Xamarin

🎤 Podcasts

🎥 Videos

.NET Stacks

You might also like

Saying goodbye to The .NET Stacks

Saying goodbye to The .NET Stacks

In this post, I'm writing a quick note to say I'm ending The .NET Stacks.

Dave Brock
Dave Brock
.NET Stacks
The .NET Stacks #68: 🍿 What a week

The .NET Stacks #68: 🍿 What a week

In this issue, we talk about an eventful week in the .NET community.

Dave Brock
Dave Brock
.NET Stacks

Featured Posts

Low Ceremony, High Value: A Tour of Minimal APIs in .NET 6

Low Ceremony, High Value: A Tour of Minimal APIs in .NET 6

Ask About Azure: Why do resource groups need a location?

Ask About Azure: Why do resource groups need a location?

Use Azure Functions with .NET 5

Use Azure Functions with .NET 5