MVC @model directive should respect the nullability of the type supplied

[willdean]

Apologies if this has been publicly discussed already, but I can't find anything about it and the terms are generic enough to make searching very difficult.

It seems that .NET6 (RC2, with VS2022 RC2) has marked the model passed to an MVC page via an @model directive as nullable, irrespective of whether the type supplied by the view's author is nullable or not.

I'm sure this has some technical correctness about it, but it seems here that this may fall on the wrong side of the trade-offs that surround the use of nullable reference types. (I love compiler warnings, and was putting <nullable>enable</enable> all over stuff from the first minute it was available.)

We now have hundreds and hundreds of warnings across views which have been written years ago. These views would have no useful function whatsoever if someone decided to call them with a null model: an NRE which ended-up in our standard exception handler would be just as good a way of handling the situation as any other.

I couldn't find a way of adding exclamation marks to the @model line itself, and the fact that we haven't marked our model types as nullable is not respected by the compiler.

Am I missing something here, or are we really expected to choose between adding exclamation marks all over "legacy" views or foregoing nullable-enable altogether? Or is there perhaps a new alternative to the @model directive which uses the type supplied without inferring a "?" on the end? Changing one line at the top of the view would be better than mods all over it.

The only example I can find in current templates is in "Error.cshtml", which contains some of this sort of stuff: @if (Model?.ShowRequestId ?? false) - which may well be a good idea in an error handler where you really do want to avoid exceptions. In most other views it seems much better to throw the NRE and know about the catastrophe than to undetectably (from the site-owner's POV) have bits of pages mysteriously go missing.

[pranavkm]

@willdean thanks for the feedback. We had another issue complain about this - #37510, and I agree this is something we need to improve. For the time being, my recommendation would be to consider using a custom base type for the view: #37510 (comment)

[willdean]

@pranavkm Thanks for this - I had seen that issue but do not really have any proper idea how to apply information about Razor Page base classes to MVC views.

According to the linked docs "The @model directive specifies the type of the Model property. The directive specifies the T in RazorPage". Is this also true in MVC Views - i.e. do they derive from RazorPage as well?

[pranavkm]

The directive specifies the T in RazorPage

Yup. The nomenclature is a bit weird, but a Razor view is composed of many individual RazorPage files and individual .cshtml files derive from RazorPage<T>.

[willdean]

In case it's useful to other people to work around this problem, create a class like this:

public abstract class NonNullableViewBase<TModel> : RazorPage<TModel>
{
    protected new TModel Model => base.Model!;
}

and then in .cshtml files where the tools are complaining that Model might be null, replace the @model MyViewModelType line at the top of the file with:

@inherits NonNullableViewBase<MyViewModelType>

You will have to make sure that the NonNullableViewBase is in a namespace which has a using somewhere.

One could probably do this with a regex based find-and-replace in Visual Studio if so-minded.

I still think that the problem could have a better solution than this, but this may help people for now. (Personally I think the annotation change in RazorPage was a mistake and along with the way the template deals with this will encourage a cure that's worse than the original disease)

Update: It turns out that the above fixes a whole bunch of warnings, but screws-up whatever magic is used to make the type inference for the HTML helpers (e.g. Html.CheckBoxFor(m => m.MyProp)) work. Not sure if @pranavkm has any suggestion about what's going on there? Even leaving the @model directive in doesn't help - something decides that the HTML helpers are trying to work with a dynamically-typed model and chokes.

[razzmatazz]

I still think that the problem could have a better solution than this, but this may help people for now. (Personally I think the annotation change in RazorPage was a mistake and along with the way the template deals with this will encourage a cure that's worse than the original disease)

I concur

[DavidZidar]

This nullability issue breaks nearly every view I have written, most views do not make sense without the model. The cure is indeed worse than the disease. This feature really shouldn't have been enabled until it was fully baked with proper nullability support in the @model attribute.

As a workaround I'm using Guards from the Diagnostics package in the Windows Community Toolkit, it seems like the least verbose option. Not great that I have to add this line to the top of nearly every view I have though.

@{ Guard.IsNotNull(Model, nameof(Model)); }

ArgumentNullException works too but it's a little bit more verbose:

@{ if (Model is null) throw new ArgumentNullException(nameof(Model)); }

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.