Hey @dotnet/aspnet-build, looks like this PR is something you want to take a look at.

@dotnet/aspnet-blazor-eng any recent changes that could explain this?

Hm, I can't find any recent changes on our end that would cause this. Interesting that this is happening in an SDK update PR. I also see that there are some encoding-related tests failing - maybe it was a Razor compiler change?

@TanayParikh / @MackinnonBuck are you guys following up on the regression in Razor causing these test failures, do you want me to skip the tests to unblock the SDK update or do you want to try and track down the root cause?

Let's ask @ryanbrandenburg: Do you know if there were any recent changes in Razor that could explain these failures?

@MackinnonBuck it looks like @ryanbrandenburg hasn't gotten back to us on this. Any other ideas on what we can do to get this unblocked?

Spoke to @MackinnonBuck offline. The short answer is that I don't have context on anything that might cause a change in behavior like this but suggested checking with the Razor Compiler folks.

@mitchdenny, Ryan suggested I communicate internally with the Razor team (since he works on tooling), and I'm still waiting to get accepted into the MS Teams group that lets me do that.

@jaredpar Do you know if there are any recent changes to the Razor compiler that might be causing these failures?

The failing test is different now, more like a product defect/regression:

Related to this tag helper

Expected: ··· &lt; 4&lt;/b&gt;\r\n<pre>Default encoder: Inner knows &lt;b&gt···
Actual:   ··· &lt; 4&lt;/b&gt;\r\n<inner>Inner knows &lt;b&gt;1 &lt; 4&lt;/b···

This is the view that is rendered using the previous Tag Helper

This is the expected output

I believe there is something related to the way the tag helper is configured with

[HtmlTargetElement("pre")]
[HtmlTargetElement("inner")]
[OutputElementHint("pre")]

@mkArtakMSFT can someone look into it?

The failing test is different now, more like a product defect/regression

I'm still seeing the same failures along with the one you pointed out. I don't think it's on our side since we haven't had any changes there since before the last successful SDK bump.

I believe there is something related to the way the tag helper is configured

That would be strange since that configuration hasn't changed since @dougbu wrote it in early 2016. I know the Razor folks had a recent bug bash, but I would think it's unlikely that the test is faulty and has been false-passing for that long. @MackinnonBuck what do you think?

@Nick-Stanton someone with Tag Helper knowledge might help confirm that the actual output is wrong, and why it generates it. Maybe a razor compiler problem and then ask for help. Probably the two issues have the same root cause.

I don't remember the code very well -- 2016 was a while ago 😉 But I suspect having two HtmlTargetElement attributes could change behaviour due to Razor SDK changes. Or something is overriding the OutputElementHint attribute now. Either way, calling in Razor SDK folks sooner rather than later makes sense to me.

It looks like dotnet/razor#8267 will probably fix the failures we're seeing.

It looks like dotnet/razor#8267 will probably fix the failures we're seeing.

Yes, this should fix the issues you're seeing here. It'll take a short while to flow into the SDK, but I can ping back here when its available.

@chsienki @MackinnonBuck It looks like .NET 8.0.1xx SDKs are currently being built from the release/dev17.6 branch which doesn't yet include the fix from dotnet/razor#8267. Do we need to backport it? When will the SDKs start picking up the changes from the main branch? When we create the release/dev17.7 branch?

Looks like razor code flow isn't set up correctly to flow into main right now. We're looking at it and I'll let you know as soon as it should be available.

@chsienki I won't hold you to it, but any ETA so I can update build-ops?

We merged into the SDK early this morning: dotnet/sdk#30765

It looks like SDK -> Installer has been blocked for a few days, but this following PR contains the fix and should produce a new SDK as soon as it merges and builds dotnet/installer#15586

/azp run