Running dotnet watch with a EditForm component with @bind-Value breaks with error "condition `<disabled>' not met"

[ShoarW]

Running my project I've noticed that the hot reload will exit/crash if it finds a with a @bind-Value inside of it.

Files looks like

<EditForm Model="@Login" OnValidSubmit="HandleValidSubmit">
    <DataAnnotationsValidator />
    <ValidationSummary />

    <InputText @bind-Value="Login.Email" />
    <InputText @bind-Value="Login.Password" />
    <button class="btn btn btn-lg btn-primary" type="submit">Sign in One</button>
</EditForm>

@code {
    private LoginResult Login = new LoginResult();
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount += 30;
    }

    private void HandleValidSubmit()
    {
        Navigation.NavigateTo("/");
    }
}

Crashes with when navigating to the page

* Assertion at /__w/1/s/src/mono/mono/metadata/assembly.c:1373, condition `<disabled>' not met
dotnet.6.0.0-preview.4.21253.7.js:1:18291

Downgrading the preview packages to Preview 3 (not the SDK) will not crash the application.

I have created a reproduction of the issue here - You will need Preview4 and latest Visual Studio Preview

https://github.com/ShoarW/BlazorHotReloadPreview4

[mkArtakMSFT]

@lambdageek do you have a separate issue tracking this already?

[lambdageek]

Very strange: the assert is hit when you start the app via dotnet watch and navigate to the Counter page - you don't need to edit any code.
That assertion is hit if a managed AppDomain.CurrentDomain.AssemblyLoad event throws an unhandled exception.
Does the hot reload agent hook up to that event? /cc @pranavkm

[pranavkm]

It does. That sounds like a bug in Blazor's hot reload agent. I'll look at this further.

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.