Compile issue in razor files for model expressions "!@"

[joopscheer]

After installing SDK version 8.0.300, we have compile issues in razor (cshtml) files. This was not the case in previous SDK versions. If we fix the SDK version to an earlier version, there are no compile issues either.

Errors:

/Path/FileName.cshtml(11,121): error CS1525: Invalid expression term '' 
/Path/FileName.cshtml(11,121): error CS1002: ; expected 
/Path/FileName.cshtml(11,121): error CS1646: Keyword, identifier, or string expected after verbatim specifier: @ 

It involves the following code:

<label asp-for="Name" taghelper-hidden="!@Model.HasName"></label>

The following code change fixes it:

<label asp-for="Name" taghelper-hidden="@(!Model.HasName)"></label>

Probably related to #10186 and fixed by PRs of @333fred?

[jjonescz]

Is the @ modifier necessary? Wouldn't this work too?

<label asp-for="Name" taghelper-hidden="!Model.HasName"></label>

[joopscheer]

It does. Our TagHelper expects a bool value. Previously, not sure how many versions ago, it was mandatory to add the @ expression to get the bool value. Now it looks like the TagHelper sees the HtmlAttributeName as a model espression?

[HtmlTargetElement(Attributes = HiddenAttributeName)]
public class HiddenTagHelper : TagHelper
{
    private const string HiddenAttributeName = "taghelper-hidden";

    [HtmlAttributeName(HiddenAttributeName)]
    public bool Hidden { get; set; }

    public override void Process(TagHelperContext context, TagHelperOutput output)
    {
        if (Hidden)
        {
            output.SuppressOutput();
        }
        else
        {
            base.Process(context, output);
        }
    }
}

[joopscheer]

It goes wrong not only with the !@ expression, but also with the @ character that is not at the beginning of the value. See the examples below.

<select asp-for="CountryId" asp-items="await @Model.CountriesAsync()"></select>

<a href="/" taghelper-hidden="@Model.Month == @Model.CurrentMonth">Current</a>

In the sample above with the equals comparison the compiler comlains about the second @.

<label asp-for="Name" taghelper-hidden="@Model.HasName"></label>

The above example works fine.

In our code, this leads to hundreds of compile issues after installing version 8.0.300. Is there going to be a fix for this?

[joopscheer]

With the latest preview 9.0.0-preview.5.24256.2, everything works fine. No compile issues.

[333fred]

I don't know if we are planning to update 8.0.300 with my bugfix, but we can certainly see if it meets the servicing bar. @jaredpar?

[peterkline]

I would like to please ask that this gets fixed on 8.0.30X. This is currently breaking our builds after we upgraded to cover the CVEs that the lastest release fixes.

[mfalconi-perle]

I also started getting a similar issue passing data to partial views if the partial was contained inside a razor if or foreach. This spontaneously started two days ago too, and i had to change 700 files to get compilation to work.

@foreach (var (product, index) in Model.Products.WithIndex())
                    {
                        <partial name="_productIndexCard" model=@product view-data='new ViewDataDictionary(ViewData) { { "index", @index}, { "lazyLoadStart", 1 } }' />
                    }

These built fine a few days ago then 2 days ago suddenly every page that had this was throwing the exact same error message as OP. I had to remove all the @ from the vars being passed. I feel like this is a pretty important breaking bug.

[danieljaybarber]

Not sure if it helps, but I noticed a similar issues with builds today.

Previously had code like the following (notice the space after the " and before the @):
<label asp-for="Name" taghelper-hidden=" @Model.HasName"></label>

I cleaned up all the '@' tags in the project to remove any unnecessary spaces in the quotes and all builds seem to be working fine now. Like @mfalconi-perle above, these builds were working fine for us last week without issue with the spaces in the quotes.

Apologies if the above does not provide any help, just figured I'd throw in what I experienced today.

[jaredpar]

Thanks for reporting this issue. This is a dupe of #10186 which we're working on back porting to 8.0.300 / 17.10. Going to close this and use #10186 as the primary tracker.