[10.0.300] RZ1021 falsely raised for HTML tags inside `@if` blocks

[Ghostbird]

Sorry, this should have been filed at dotnet/roslyn

Summary

After upgrading from .NET SDK 10.0.203 → 10.0.300, the Razor source generator falsely reports RZ1021: Markup in a code block must start with a tag and all start tags must be matched with end tags for perfectly valid markup. The generated .g.cs is corrupted: the parser eats the leading <tagname and emits everything after as raw C#, which then triggers cascading CS0102/CS9348/CS0101 errors across the whole assembly.

The trigger is surprisingly narrow:

• The element must be inside a Razor code block (@if {}, @foreach {}, …).
• The enclosing block must be inside outer markup (e.g. a <div>).
• The tag name must be 4 or more characters (3-char names like <br>, <img>, <hr>, <col>, <wbr> work fine).
• The element's line must be tab-indented or have no indentation. Space indentation works.

Minimal repro

Views/Home/Repro.cshtml:

<div>
	@if (true)
	{
		<input />
	}
</div>

(All indentation is tabs.) Build with dotnet build:

Views/Home/Repro.cshtml(4,5): error RZ1021: Markup in a code block must start with a tag and all start tags must be matched with end tags.  Do not use unclosed tags like "<br>".  Instead use self-closing tags like "<br/>".

Followed by ~10 cascading CS errors in the generated _Repro_cshtml.g.cs.

What makes it succeed

UPDATE: Spoilered, because @Magehernan encountered this in a scenario that did not match my findings.

• It occurred for simple <div> tags, no need for 4+ characters
• It occurred without an outer <div> tag.

Any one of the following changes makes the build succeed:

1. Replace tab indentation with spaces.
2. Use a tag name with ≤ 3 characters (<br />, <img />, <hr />, <col />, <wbr />).
3. Remove the outer <div> wrapper.
4. Disable the source generator: <UseRazorSourceGenerator>false</UseRazorSourceGenerator>.

Tag name length matrix (with tab indent, inside <div> + @if)

Tag	Result
<a />, <ab />, <abc />	OK
<abcd />, <abcde />	RZ1021
<br />, <img />, <hr />, <col />, <wbr />	OK
<input />, <meta />, <link />, <area />, <base />, <embed />, <source />, <track />	RZ1021
Tag with hyphen (<aaa-bbb-ccc />)	OK

So this is not about void elements specifically (otherwise <br> and <input> would behave the same); the discriminator looks like raw tag-name length combined with leading whitespace classification.

Inspecting the generated file

With EmitCompilerGeneratedFiles=true, the generated _Repro_cshtml.g.cs shows the parser bailed early — it emits <input as the start of a markup element, then puts the rest of the line and following lines as raw C# code inside a method body, producing a stream of <invalid-global-code> types that conflict with every other Razor file in the assembly. Because the cascading CS errors land in AspNetCoreGeneratedDocument, a single bad .cshtml makes every other view in the project fail to compile (CS0101, CS0102 for ModelExpressionProvider/Url/Component/Json/Html).

Environment

• SDK: .NET SDK 10.0.300 (commit caa81fa497)
• OS: Debian 13 (Linux x64)
• Previously working: 10.0.203
• Affected project: Microsoft.NET.Sdk.Web, <TargetFramework>net10.0</TargetFramework>
• Reproduces in both Debug and Release configurations.
• Reproduces without any tag helper imports (removing @addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers does not fix it).

Impact

This silently broke a real production project after a system-wide SDK update. The error message (Do not use unclosed tags like "<br>") is actively misleading because the actual markup is well-formed self-closed <input />, and <br> itself is one of the tags that does not trigger it. A single offending file cascades into 100+ CS errors across the project, making it hard to identify the root cause without inspecting the generated source.

Workaround

<PropertyGroup>
  <UseRazorSourceGenerator>false</UseRazorSourceGenerator>
</PropertyGroup>

[davidwengier]

@Ghostbird it's fine to log issues here, and since it doesn't look like you've logged anything in Roslyn yet, I'll reopen this one.

[davidwengier]

@Ghostbird I'm afraid that creating tests in our repo for this scenario does not repro the issue.

I even tried on my little debian box, which is otherwise a pretty clean setup:

I wonder if you could attach a binlog from a build, whether that might shed any light on this. dotnet build -bl will produce one.

[Ghostbird]

Yesterday I had created this issue and then downgraded my dotnet-sdk-10.0 using sudo apt-get install dotnet-sdk-10.0=10.0.204, so I could continue working. Today I wanted to retest the reproduction after @davidwengier's comment, and I updated the .NET SDK 10.0 again to 10.0.300 (just using a plain sudo apt-get dist-upgrade).

Suddenly the minimal reproduction didn't reproduce the error any more. So I tried the main repo, and now that builds fine too using this version.

I have no idea what caused the issue to arise in the first place, nor what fixed it. I didn't even reboot my machine in between. I only suspend it at the end of the work-day and do a full shutdown for the weekend.

Sorry for the report, the issue must have been on my machine.

[Magehernan]

Hi, today i was seening this exact issue using arch and rider... so i restart the system and now build fine so maybe y something that stay in memory and make this happend... so if anyone see this error try to restart maybe works for you too.

[Magehernan]

So it continue happening when i edit the razor component some times start failing.
I found that if i kill the process /usr/share/dotnet/sdk/10.0.301/Roslyn/bincore/VBCSCompiler -pipename:RKuBiVVAJzXIQZnCh9IrQIK5z2iTyol6ykfZOpH40HA
i compiles fine again.

[davidwengier]

@Magehernan Can you grab a binlog from a build that has this issue. See my comment above

[Magehernan]

Hi @davidwengier here is the binlog for a empty project that only i add this

@if(true) { 
    <div></div>
}

and the error start ocurring.
i change the extension file for upload, rename it to .binlog
msbuild.zip