ASP.NET Core updates in .NET Core 3.1 Preview 1

Daniel Roth

.NET Core 3.1 Preview 1 is now available. This release is primarily focused on bug fixes, but it contains a few new features as well.

Here’s what’s new in this release for ASP.NET Core:

  • Partial class support for Razor components
  • Pass parameters to top-level components
  • Support for shared queues in HttpSysServer
  • Breaking changes for SameSite cookies

Alongside this .NET Core 3.1 Preview 1 release, we’ve also released a Blazor WebAssembly update, which now requires .NET Core 3.1. To use Blazor WebAssembly you will need to install .NET Core 3.1 Preview 1 as well as the latest preview of Visual Studio.

See the release notes for additional details and known issues.

Get started

To get started with ASP.NET Core in .NET Core 3.1 Preview 1 install the .NET Core 3.1 Preview 1 SDK.

If you’re on Windows using Visual Studio, for the best experience we recommend installing the latest preview of Visual Studio 2019 16.4. Installing Visual Studio 2019 16.4 will also install .NET Core 3.1 Preview 1, so you don’t need to separately install it. For Blazor development with .NET Core 3.1, Visual Studio 2019 16.4 is required.

To install the latest Blazor WebAssembly template run the following command:

dotnet new -i Microsoft.AspNetCore.Blazor.Templates::3.1.0-preview1.19508.20

Upgrade an existing project

To upgrade an existing ASP.NET Core 3.0 project to 3.1 Preview 1:

  • Update any projects targeting netcoreapp3.0 to target netcoreapp3.1
  • Update all Microsoft.AspNetCore.* package references to 3.1.0-preview1.19506.1

See also the full list of breaking changes in ASP.NET Core 3.1.

That’s it! You should now be all set to use .NET Core 3.1 Preview 1!

Partial class support for Razor components

Razor components are now generated as partial classes. You can author the code for a Razor component using a code-behind file defined as a partial class instead of defining all the code for the component in a single file.

For example, instead of defining the default Counter component with an @code block, like this:

Counter.razor

@page "/counter"

<h1>Counter</h1>

<p>Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
    int currentCount = 0;

    void IncrementCount()
    {
        currentCount++;
    }
}

You can now separate out the code into a code-behind file using a partial class like this:

Counter.razor

@page "/counter"

<h1>Counter</h1>

<p>Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

Counter.razor.cs

namespace BlazorApp1.Pages
{
    public partial class Counter
    {
        int currentCount = 0;

        void IncrementCount()
        {
            currentCount++;
        }
    }
}

Pass parameters to top-level components

Blazor Server apps can now pass parameters to top-level components during the initial render. Previously you could only pass parameters to a top-level component with RenderMode.Static. With this release, both RenderMode.Server and RenderModel.ServerPrerendered are now supported. Any specified parameter values are serialized as JSON and included in the initial response.

For example, you could prerender a Counter component with a specific current count like this:

@(await Html.RenderComponentAsync<Counter>(RenderMode.ServerPrerendered, new { CurrentCount = 123 }))

Support for shared queues in HttpSysServer

In addition to the existing behavior where HttpSysServer created anonymous request queues, we’ve added to ability to create or attach to an existing named HTTP.sys request queue. This should enable scenarios where the HTTP.Sys controller process that owns the queue is independent to the listener process making it possible to preserve existing connections and enqueued requests between across listener process restarts.

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            // ...
            webBuilder.UseHttpSys(options =>
            {
                options.RequestQueueName = "MyExistingQueue",
                options.RequestQueueMode = RequestQueueMode.CreateOrAttach
            })
        });

Breaking changes for SameSite cookies

This release updates the behavior of SameSite cookies in ASP.NET Core to conform to the latest standards being enforced by browsers. For details on these changes and their impact on existing apps see https://github.com/aspnet/Announcements/issues/390.

Give feedback

We hope you enjoy the new features in this preview release of ASP.NET Core! Please let us know what you think by filing issues on GitHub.

Thanks for trying out ASP.NET Core!

37 comments

Discussion is closed. Login to edit/delete existing comments.

  • Daniel Smith 0

    Congrats on getting partial classes working – I’ll definitely be using this from now on 🙂

    I suspect a large proportion of people are going to prefer partial classes since it keeps the markup and code cleanly separated. Are there any plans to update the project templates to use partial classes? It’d be nice if Add New Item > Blazor Component item template defaulted to the partial class structure as well.

    • Keith Williams 0

      I think I will prefer the single file components for passive components with parameters (where seeing parameters in the same page as the bindings improves readability)…but VS Code’s handling of .razor files sometimes leaves a bit to be desired. Omnisharp likes to repeatedly crash and stop whenever you mistype a tag and intellisense and code highlighting sometimes do not work properly inside of code and function blocks. I’m hoping razor code behind files will be treated as proper .cs files by Omnisharp and I can stop pulling my hair out or repeatedly mashing the ‘Restart Omnisharp’ command.

      • Daniel RothMicrosoft employee 0

        I’m sorry to hear your having so many issues with the Visual Studio Code tooling for Blazor! The Blazor tooling in Visual Studio Code is still in its alpha stages. Please file issues for any problems you hit in the https://github.com/aspnet/aspnetcore/issues repo and we’ll take a look.

        • Keith Williams 0

          I’m aware that using Visual Studio Code for Blazor today is perhaps a bit…premature, so I’m not put off by the issues I’ve run into. Despite the negative tone, I am feeling optimistic about code behind classes. Should issues with Visual Studio Code tooling for Blazor should be submitted to the aspnetcore repo? Is there a particular tag/label for that? I was hesitant to submit any issues in the past since I haven’t seen any lists of known limitations for the Visual Studio Code Blazor tooling and wouldn’t want to submit issues for something that isn’t expected to work.

          • Daniel RothMicrosoft employee 0

            Yup, we track Razor tooling issues for Visual Studio Code in the aspnet/aspnetcore repo using the feature-razor.vscode tag.

    • Daniel RothMicrosoft employee 0

      Hi Daniel,

      Currently we favor authoring Razor components as a single file, but we understand that many folks prefer the code-behind pattern so both models are supported. We don’t have any immediate plans to switch the pattern used by the project templates or the item template, but we do take this feedback under consideration.

      • Milos Stefanovic 0

        Thanks for all the new stuff Daniel. Btw, I think that most of the guys prefer the code behind, not only the pattern is easier to grok for win\web forms folks, it’s also a very good practice, proven in battle for decades. Only the new kids, cult worshipers, like over-engineered patternitis driven development.

        Also, I think it’s much easier to re-write the old asp.net webforms apps to Blazor, if you already have code behind by default.

        Of course, this behavior by default is nice to have, not a show stopper 🙂 we like the blazor already, and we want it to be even better.

      • Severin, Dale 0

        I also favor authoring Razor components as a single file. I was never a fan of looking at multiple locations. But I also recognize that many like the separation of code and it is more readable for them. Thanks for the release of the 3.1 preview. I am thankful that my MVC views can now pass parameters to top-level components during the initial render like in earlier 3.0 previews.

  • Shiyam Salam 0

    Thanks for the partial class feature. However, I am still forced to use @inherits BaseComponent in my razor component since all of my components are inherited from this base class.

    As for the new “Left Tab Layout” Visual Studio feature, is there a way to auto hide “Tabs” window?

  • Maksim Makushenko 0

    What about styles personalized for each component? For example, Counter.razor is a rendering tree, Counter.razor.cs is logic, Counter.razor.css is styles.

    • Keith Williams 0

      In your example, would that be assuming that the styles in Counter.razor.css are scoped and then merged at build time (similar to Angular)?

      We’ve faked something like this in one of our projects by adding a SASS build step into our project file and manually scoping styles to their component by prefixing the classes in each scss file with their component name, but it would be kind of nice if there was a way to do this that didn’t require NodeJS and that could handle the scoping automatically.

  • Samer Awajan 0

    Amazing to see this preview with almost no breaking changes, so it increases developer confidence in moving to 3.x.

    • Daniel RothMicrosoft employee 0

      Yup, .NET Core 3.1 should be a seamless upgrade. Thanks for giving it a try!

  • Ben Hayat 0

    Daniel, I have one important question to ask;

    When we learned about the future of .Net (.Net 5), one thing that became clear that .Net 5 will be more compact and will replace Mono in the cases of devices, mobile, Xamarin and Client Blazor which will be available in Nov. of 2020
    Hearing that, has given me a lot motivation to consider Client Blazor with a smaller app’s footprint.

    However, we also recently heard by Scott Hunter that MSFT is planing to have an official release of Client Blazor in May of 2020. And here is my question:
    Will the May release be made with the current Mono Runtime or will it be made with an early release of .Net 5? If the former, does this first release create a bigger App’s footprint until we get the .Net 5? And will .Net 5 make the full size smaller eventually (by Nov. 2020)?

    Size gets noticeable when users are using the app on Mobile when WiFi is not available. Our app will have 90% of it’s usage by people on-the-go.

    I would appreciate if you shed some light on this topic.
    Thank you as always!
    ..Ben

    • Daniel RothMicrosoft employee 0

      Hi Ben,

      The initial release of Blazor WebAssembly will be based on the existing mono.wasm runtime. In the .NET 5 time frame we expect Blazor WebAssembly to start using the core framework libraries from .NET Core instead of the existing mono based implementation. Not much more is know about the WebAssembly runtime implementation for .NET 5 at this point. It’s too early to know what impact .NET 5 will have on app size, but the the goal of course is to make it as small as possible while also considering competing concerns like runtime performance and available functionality.

  • Alex Bedel Miaffo Zefack 0

    Hi,
    It is great. But unfortunately my visual studio is not generating the backend file for the view. C-Sharp code and the view code are still in the single page after all configurations.
    The more, I am getting the following error:
    Severity Code Description Project File Line Suppression State Suppression State
    Error rzc generate exited with code 2. Justice.Web C:\Program Files\dotnet\sdk\3.1.100-preview1-014459\Sdks\Microsoft.NET.Sdk.Razor\build\netstandard2.0\Microsoft.NET.Sdk.Razor.Component.targets 106

    • Daniel RothMicrosoft employee 0

      What version of Visual Studio are you using? Please confirm that you are using the latest Visual Studio preview: https://visualstudio.com/preview.

      • Alex Bedel Miaffo Zefack 0

        I am using the latest version of VS.
        I changed the configuration to use the previews sdk
        The more, I realized that when create a new project the version remain 3.0 but the templates are 3.1 previews.
        The problem pop up when changing the version from 3.0 to 3.1

        as you can see below

        Project Sdk=”Microsoft.NET.Sdk.Web”

        PropertyGroup
        TargetFramework netstandard2.0 /TargetFramework
        RazorLangVersion 3.0/RazorLangVersion
        /PropertyGroup

        ItemGroup
        PackageReference Include=”Microsoft.AspNetCore.Blazor” Version=”3.1.0-preview1.19508.20″ /
        PackageReference Include=”Microsoft.AspNetCore.Blazor.Build” Version=”3.1.0-preview1.19508.20″ PrivateAssets=”all” /
        PackageReference Include=”Microsoft.AspNetCore.Blazor.HttpClient” Version=”3.1.0-preview1.19508.20″ /
        PackageReference Include=”Microsoft.AspNetCore.Blazor.DevServer” Version=”3.1.0-preview1.19508.20″ PrivateAssets=”all”
        /ItemGroup

        /Project

        @page “/counter”

        Counter

        Current count: @currentCount

        Click me

        @code {
        private int currentCount = 0;

        private void IncrementCount()
        {
        currentCount++;
        }

        }

        • Daniel RothMicrosoft employee 0

          I am using the latest version of VS. I changed the configuration to use the previews sdk

          Which specific VS version are you using? You can find the version number under Help -> About. It sounds like you’re using the latest stable version of VS (16.3) when you need to use the latest preview version when working with the .NET Core 3.1 SDK. Doing Blazor development with .NET Core 3.1 in VS 2019 16.3 is not supported. You need to use VS 2019 16.4.

  • Gauthier M. 0

    Ah ! Partial class is cool. I will move to this instead of inherits from customs componnent 🙂

  • Jason Chen 0

    This release is kind of unstable?

    issue #1:
    I have several pages that will get System.NullReferenceException: ‘Object reference not set to an instance of an object.’ upon loading. It seems the html part is being rendered before OnInitializedAsync() completes.

    • Daniel RothMicrosoft employee 0

      Hi Jason,

      You get a NullReferenceException because you’re initializing cProfile in OnInitializedAsync using an async call. The call to OnInitializedAsync completes while the GetProfile call is still in progress and the component is rendered while cProfile is still null. The common pattern for dealing with this is to put a null check in you rendering logic and display some placeholder UI while the async initialization logic is still in flight:


      @if (cProfile == null)
      {

      Loading...

      }
      else {
      @* Normal rendering logic here *@
      }

      For the routing issue, Blazor doesn’t support complex route parameters where the route parameter is part of a path segment. But @page “/Profile/{id}” should work. If you’d like us to support complex route parameters of this form, please let us know by filing an issue: https://github.com/aspnet/aspnetcore/issues.

  • FrankJeff 0

    Installed VS 16.4, I create a new Blazer Web Assembly project and build it. Then Ctrl + F5 to execute … nothing happens. If I copy paste the localhost link from the outpane the web app is displayed. Is anyone else seeing this?

    • Daniel RothMicrosoft employee 0

      Thanks for sharing with us this feedback! Could you please create a Visual Studio Feedback issue for the behavior you are seeing so we can investigate?

  • Keith Frechette 0

    Is there any thought being given to allowing the code within a @code section to not be highlighted as it is in normal Razor code, without turning it off for all Razor code? While I appreciate the different background color of code when used in normal Razor code where there is lots of mixed HTML and C#, I find it distracting within a @code section, where the content is expected to be code. If anything, I’d find it more useful to have the background highlighting be reversed in a @code section, with HTML being given the “highlighted” background color.

    • Daniel RothMicrosoft employee 0

      That’s great feedback! Please open a Visual Studio Feedback issue with this feedback, and we’ll take a look.

Feedback usabilla icon