[dotnet-sdk-9.0.100-preview.3.24175.24] CS1646 error when building Hawaso

[Junjun-zhao]

Application Name: Hawaso
OS: Windows 10 22H2
CPU: X64
.NET Build Number: dotnet-sdk-9.0.100-preview.3.24175.24
App Source Location Checking at:
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2012415

Github Link:
https://github.com/VisualAcademy/Hawaso

Verify Scenarios:

1. Windows10 21h2 x64 + dotnet-sdk-9.0.100-preview.3.24175.24: Fail
2. Windows10 21h2 x64 + dotnet-sdk-9.0.100-preview.2.24129.7: Pass
3. Windows10 21h2 x64 + dotnet-sdk-8.0.202: Pass

Description:
CS1646 error shows when we build Hawaso\Hawaso project with dotnet-sdk-9.0.100-preview.3.24175.24

Minimal Repro steps (Demo attached):
Demo.zip

The machine has dotnet-sdk-9.0.100-preview.3.24175.24 installed.

1. Create default 8.0 ASP .NET Core Web App(Razor Pages).
2. Create class MyTagHelper.cs:

using Microsoft.AspNetCore.Razor.TagHelpers;
using System;
namespace Demo
{
    [HtmlTargetElement("mytag", Attributes = "myattr")]
    public class MyTagHelper:TagHelper
    {
        [HtmlAttributeName("myattr")]
        public int MyAttr { get; set; }
    }
}

3. Import taghelper in _ViewImports.cshtml:

@using Demo
@namespace Demo.Pages
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers
@addTagHelper *, Demo

5. Add the following code in Index.cshtml:

@page
@model IndexModel
@{
    ViewData["Title"] = "Home page";
    int count = 0;
}
<div>
    <mytag myattr='Convert.ToInt32(@count)'></mytag>
</div>

7.Build the app with 9.0.100-preview.3.24175.24 SDK

Expected Result: Build successfully.
Actual Result:

Build failed with error: CS1646 Keyword, identifier, or string expected after verbatim specifier: @.

dotnet info:

.NET SDK:
 Version:           9.0.100-preview.3.24175.24
 Commit:            09d6f381e6
 Workload version:  9.0.100-manifests.77bb7ba9
 MSBuild version:   17.10.0-preview-24175-03+89b42a486

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19045
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\9.0.100-preview.3.24175.24\

.NET workloads installed:
There are no installed workloads to display.

Host:
  Version:      9.0.0-preview.3.24172.9
  Architecture: x64
  Commit:       9e6ba1f68c

.NET SDKs installed:
  9.0.100-preview.3.24175.24 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 9.0.0-preview.3.24172.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 9.0.0-preview.3.24172.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 9.0.0-preview.3.24175.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

@dotnet-actwx-bot @dotnet/compat

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[Junjun-zhao]

@marcpopMSFT Could you please help check this issue and confirm if it is a blocker for .NET 9 Preview3? Thanks.

[marcpopMSFT]

This should be moved to the Roslyn repo most likely but I don't have permissions to move it. @jaredpar

[jaredpar]

@chsienki is this in the razor generator or roslyn?

[chsienki]

@jaredpar from a glance it looks like razor

[chsienki]

Ah yeah, this is a fallout of the runtime fuse changes (so a real break). That @ in count isn't a razor @ but a C# identifier escape character. We're now breaking those tokens into separate lines, so the C# parser thinks we're trying to start a quoted string.

#nullable restore
#line (8,20)-(8,36) "C:\projects\scratch\razorrepro9p3\Pages\Index.cshtml"
Convert.ToInt32(

#line default
#line hidden
#nullable disable
#nullable restore
#line (8,36)-(8,37) "C:\projects\scratch\razorrepro9p3\Pages\Index.cshtml"
@

#line default
#line hidden
#nullable disable
#nullable restore
#line (8,37)-(8,42) "C:\projects\scratch\razorrepro9p3\Pages\Index.cshtml"
count

#line default
#line hidden
#nullable disable
#nullable restore
#line (8,42)-(8,43) "C:\projects\scratch\razorrepro9p3\Pages\Index.cshtml"
)

[chsienki]

@Junjun-zhao this is a real issue, but niche enough that the Razor compiler team don't consider it a blocker for P3.

[Junjun-zhao]

@333fred We verified this issue with the latest build 9.0.100-preview.5.24227.1, it is still reproducing. Could you please help to confirm whether the fix is merged into the build? Thanks.

[333fred]

@Junjun-zhao can you link to that specific build please? Hard to verify without SHAs. Thanks.

[Junjun-zhao]

@333fred Please try with the build getting from https://aka.ms/dotnet/9.0.1xx/daily/dotnet-sdk-win-x64.exe

[333fred]

Ok, I've dug into this a bit more; from what I can tell, all Fuse did here was expose the fact that @ breaks various bits of tag helper rewriting and always has. Runtime code generation was simply smushing things together more than design time was, and I'm guessing there have been many phantom design-time errors for this scenario for a long time. Tag helper rewriting needs to be smarter to handle this case.

[333fred]

And, to be clear, #10232 did not actually fix this, as I misunderstood the cause of the errors in this sample.

[Junjun-zhao]

Thank you @333fred. We verified this issue with latest build dotnet-sdk-9.0.100-preview.5.24253.17, it has been fixed

[333fred]

#10386 is the backport for servicing 17.10/8.0.3xx.

[MatthewSteeples]

17.10.1 doesn't fix this issue for me as that still ships with 8.0.300 as far as I can see

If you manually install 8.0.301 and then use global.json to target that specifically then it works.

[MatthewSteeples]

Actually, 8.0.301 doesn't fix it for us so it may not be the same issue. I've got a minimal repro for it so I'll create a new issue

[jaredpar]

@MatthewSteeples the fix for this issue will be in 8.0.302 not 8.0.301.

[MatthewSteeples]

@jaredpar Not sure which issue you mean by "this" there.

If you're referring to 10426 that's great.

If you're referring to 10186 then it may be worth updating the release notes page because they indicate that 10186 is fixed and released already in 17.10.1

[jaredpar]

@MatthewSteeples it's a bit confusing because this bug exists in both VS and .NET SDK. While the bug fix goes into razor as a single change, it ships in both products and they ship on slightly different schedules.

The VS portion of the fix will impact the design time aspect of razor: errors showing up when editting, the error list in Intellisense mode, etc ... The .NET SDK portion is needed to solve the actual build errors.

[Junjun-zhao]

Hi @jaredpar @MatthewSteeples , Verified it on the latest build 8.0.302, this issue has been fixed.

1. Windows10 21h2 x64 + dotnet-sdk-8.0.302: Pass
2. Windows10 21h2 x64 + dotnet-sdk-8.0.301: Fail

[KamranShahid]

facing same issue after VS 2022 update to 17.10.1
In my system Sdk installed version viewed as dotnet-sdk-8.0.300

[ssugden]

I am still getting errors with this issue after updating VS2022 to 17.10.1.

For the following razor syntax:
="!@Model.xxxxx"
="(SomeEnum)@Model.xxxxxx"

I get:
CS0201 Only assignment, call, increment, decrement, await, and new object expressions can be used as a statement
CS1646 Keyword, identifier, or string expected after verbatim specifier: @
CS1002 ; expected
CS1525 Invalid expression term ''

[jjonescz]

@ssugden The @ symbol is not necessary in those expressions, if you remove it, they should work. Otherwise, the fix will be in SDK 8.0.302, it unfortunately did not make it into 8.0.301 (that's the version installed with VS 17.10.1), as mentioned above. You can also consider temporarily downgrading your SDK to some version before 8.0.300 by adding a global.json file.

[jpfsunolefan]

FYI, I still have the issue in VS2022 Community 17.10.1 with SDK 8.0.6

[Mimisss]

In VS2022 17.10.1, the @ symbol does not escape properly. For example:

@{
  var DropDownList = new Syncfusion.EJ2.DropDowns.DropDownList() { ... }
}
<e-grid-column ... edit="new {@params = DropDownList }" ...></e-grid-column>

where edit property expects params.

The following errors occur:

C21525   Invalid expression term 'params'
CS1002   ; expected
CS1513   } expected

The above builds successfully in VS2022 17.9.7.

Also, there is related question in SO.

[333fred]

Thanks everyone for your additional testing scenarios (both here and on vs feedback). I've added all the ones that weren't directly covered in #10471, but no code changes are required. 8.0.302, which is out today, addresses all the samples that have been submitted so far to my knowledge.

There are still a few potential issues here, mainly around some particularly esoteric cases such as a tag helper attribute value that starts with @@, or scenarios with strings inside tag helpers that contain closing quotes that thankfully no one appears to have ever actually tried to do before. #10472 tracks that problem, and trying to figure out what do about it.

I'm going to lock this thread to avoid the resolution getting buried. If anyone is still seeing issues on 8.0.302, please open a new issue so that we can triage appropriately. Thanks!