Blazor regression in 7.0.302 SDK #8718
Comments
|
I have the same issue with .NET 8 preview 4 and my project. |
|
Having issues with 7.0.302 as well. |
|
I've experienced a handful of similar issues after installing 7.0.302 (including this one specifically) For the |
Thanks for that info. Are you by any chance using components with inheritance? I think that may be related. |
|
Yes! The issue that I can't resolve right now involves an inherited component with a render fragment. The consumer cannot resolve |
I think we have this issue as well. |
|
I was going down the rabbit hole of trying to fix it, but I think I'm going to lock the version to 7.0.202 in my global.json file and wait and see if Microsoft issues a fix. Sounds like some unintended breaking changes... |
|
Looks like the issue is related to passing 'this' in a blazor component to a subcomponent as well in my case... that's where I'm having this pop up. I'm having it in places without inheritance as well, so there seems to be a few major issues here haha |
ghost
added
the
|
fyi @dotnet/razor-compiler |
|
We also digged the .g.cs files and found things like this #line 158 "C:\Users\Riley\source\repos\MudBlazor\src\MudBlazor\Components\DataGrid\MudDataGrid.razor"
rowStyle
#line default
#line hidden
#nullable disable
) + "mud-table-row");
__builder.OpenElement(125, "td");
__builder.AddAttribute(126, "class", "mud-table-cell");
__builder.AddAttribute(127, "colspan", "1000");
#nullable restorenotice the ( is flipped <tr class="mud-table-row @rowClass" Style="@rowStyle" @key="item" @onclick="@((args) => OnRowClickedAsync(args, item, tmpRowIndex))">#nullable disable
__builder.OpenElement(171, "div");
__builder.AddAttribute(172, "class", (
#nullable restore
#line 38 "C:\Users\Riley\source\repos\MudBlazor\src\MudBlazor\Components\DataGrid\MudDataGrid.razor"
_tableClass
#line default
#line hidden
#nullable disable
#nullable restore
#line 38 "C:\Users\Riley\source\repos\MudBlazor\src\MudBlazor\Components\DataGrid\MudDataGrid.razor"
_tableStyle
#line default
#line hidden
#nullable disable
) + "mud-table-pagination");
#nullable restorethis one is missing a comma (Line 38 in source) |
|
Seems this is another regression introduced by #8212. [Fact, WorkItem("https://github.com/dotnet/razor/issues/8718")]
public async Task PartialClass()
{
// Arrange
var project = CreateTestProject(new()
{
["Shared/Component1.razor"] = """
<Component2 />
""",
["Shared/Component2.razor"] = """
@inherits ComponentBase
@code {
[Parameter]
public RenderFragment? ChildContent { get; set; }
}
"""
}, new()
{
["Component2.razor.cs"] = """
using Microsoft.AspNetCore.Components;
namespace MyApp.Shared;
public partial class Component2 : ComponentBase
{
}
"""
});
var compilation = await project.GetCompilationAsync();
var driver = await GetDriverAsync(project);
// Act
var result = RunGenerator(compilation!, ref driver);
// Assert
Assert.Empty(result.Diagnostics);
Assert.Equal(2, result.GeneratedSources.Length);
}Fails with error: (This is one of the errors, my hypothesis is that the other errors reported in this issue are a consequence of it.) Btw, the workaround seems to be to remove the base class from the codebehind file (since it's also specified in the Razor file), i.e.: -public partial class Component2 : ComponentBase
+public partial class Component2 |
|
I'm experiencing a similar issue with inheritance. We defined library components as follows:
The above works fine, except where we reference the derived component in the same project in a razor file. The same error message as noted above is then shown. If we use the derived components in a different project which references the library project it also works fine. Needless to say, this scenario worked 100% with preview 3. |
It appears that removing |
|
I successfully worked around this* by updating -all- my components to use this structure, whether or not they already had BaseThing.razor
@using Namespace
@typeparam TThing
@inherits AnotherBase<TThing>
@* No other changes. *@BaseThing.razor.cs
public partial class BaseThing<TThing> : AnotherBase<TThing>, IHasInterfaces {
// Rest of code as normal - or just an empty class.
}AnotherBase.cs public partial class AnotherBase<TThing> : ComponentBase {
// Rest of code as normal - or just an empty class.
}*: "this" meaning a whole host of new build errors after installing 17.6 release VS, where 17.5 and 17.6 preview had no issues. |
@AASPLLC That's not quite right: While this Razor compiler issue did impact a significant number of users, it doesn't impact every Blazor app. Only a specific coding pattern will trigger this problem. Even so, it is a severe regression that we are working as fast as possible to get fixed. Fixing this issue requires a patch release of the .NET SDK. Whenever we ship a patch release we have to be similarly careful that the patch doesn't introduce any new issues across all .NET workloads, so it takes time to build and validate the patch before it's released.
@paulguz-datapa It's not acceptable, and we're actively working to improve our quality control processes to make sure this doesn't happen again. It caught us by surprise that this issue made it past our Razor compiler and ASP.NET Core tests. To address this, we're working to broaden our test suite. It's worth noting that one of the reasons we've had some issues with the Razor compiler recently is because of the increased level of investment that we're making in the compiler to improve performance and to enhance the Razor tooling experience. It's unfortunate that these changes introduced regressions and some of the perf gains had to temporarily be rolled back. We learned the hard way that we need more tests, but that is now getting addressed. |
@tedsmorris Please direct Pause and Resume related feedback to the corresponding GitHub issue as it isn't related to this Razor compiler regression. I can assure you we are still investing in Blazor Server as an integral part of our .NET web UI offering including supporting it as part of our full stack web UI support in .NET 8, which we think will mitigate some of the issues associated with long running circuits. We do expect to address Pause and Resume support as well in the future. |
Generally servicing fixes have a much faster turn around time: usually measured in a week or two at most. Unfortunately the timing of this regression happened in effectively at the worst possible time in our .NET SDK release cycle. The fix itself was produced very quickly to our release pipeline but it still has to wait for the .NET SDK release to occur. In the majority of cases our preference is for customers to wait for servicing fixes. As mentioned the turn around time for those is usually fairly speedy. That leads to customers pinning an old SDK for a week and then undoing that fairly shortly after. I do recognize that there are cases where we'd want a faster turn around time for patches when we hit situations like this. It's a facility we have in the C# compiler. Part of this bug made us realize we needed a similar facility for Razor and we've already begun work on that.
To be clear there is no lack of urgency here. This issue was noticed immediately and fixed very quickly afterwards. It was also a very visible issue internally. To the point we extended the servicing window for our releases to make sure this particular issue got fixed (not a small task). The delay is more a matter of the .NET SDK servicing schedule which has many other constraints on it. Looking forward though the Toolset package will give us the ability to fast patch bugs independent of the .NET SDK release.
When the previous bug shipped we looked at our quality process and how it slipped through. The core problem identified is we made a fix late in the cycle. That meant our internal consumers did not get an updated Razor compiler before RTM and hence we bypassed that quality layer. Had it been done earlier their setups would've caught it and alerted us. Effectively we lost the benefit of dogfooding. That is part of the reason why this particular bug was done extremely early in the cycle. This particular regression though didn't intersect with any of our existing test sources. It was a bit of a wake up call that our customers are using our tech in more creative ways than we are. As such we've been looking for more customer focused repos that we can use for testing in the future. |
|
Thankyou @danroth27 and @jaredpar for your detailed responses. I appreciate you reviewing your practices and taking your time over this. I, and the other subscribers to this issue, have taken a big risk and heavily invested in Blazor, and have been drumming our fingers waiting for a fix. What has got us frustrated is the lack of transparency as to why the fix existed but was not being released. Us investors are still early-ish adopters compared to React etc, and any perceived lack of action on, or problems with, Blazor scares us in to thinking Blazor maybe wasn't the right choice. For what it's worth, I really enjoy Blazor and am glad it exists. It's not perfect (I hope there's still a lot more to come with Hot Reload because I have to restart my Wasm app a lot), but it's incredibly helpful to be able to share our server-side logic with the client, and do everything in C#. It's also succint and easy to work with.
Indeed, there are many real-world open-source repos you could build as part of your testing. MudBlazor was mentioned at the start of this thread so could be a good place to start.
That great. But big changes don't seem a good fit for minor releases; .Net 8 would a better fit, with the extensive testing that would be part of the longer release cycle. |
|
VS 17.6.3 and .NET 7.0.304 are out today, both of which contain the fixes for these problems:
Again, apologies for the length of time between getting these out; normally, we can get them out sooner, but this release had security patch implications (unrelated to razor, the details are in the release notes) and those are always a longer and more complicated release procedure. |
|
I wanted to emphasize the below point in Jared's post here.
We've recently merged a change to make Razor match our C# compiler experience here, which is: if you need a compiler with some hotfix, then you can now reference the latest Toolset package from our nightly NuGet feed. This should enable you to start using fixed versions of the Razor compiler within about a day of our devs merging the fix--independently of any scheduling concerns with servicing VS and .NET SDK. |
|
I would like Microsoft to note that this issue happened somewhere between 17.5.5 & 17.6.2 because it worked for me in 17.5.5. |
|
This is still broken for .NET 8 Preview 5 |
|
Still broken in azure devops pipeline on ubuntu, when will you update the vm? |
I tried Microsoft.Net.Compilers.Razor.Toolset 7.0.0-preview.23312.9 but it is not working |
|
For anyone else stuck with a broken CI, adding this task works: |
It should work in later previews (e.g.,
Perhaps try newer version? I just tried with the broken .NET 8 Preview 5, and after installing toolset 7.0.0-preview.23313.3, the error goes away. |
Same here (and it is very anyoing since MAUI only fixes bugs in the dotnet 8 and now this bugs prevent us from using Preview 5 for our solution) |
That is not that simply... now it complains about workload wasi-experimental which cannot be installed because of missing dependencies in the azure nuget feed.... |
Do you have the feeds ordered like this? Then I think it should first use the default nuget feed and only then the Azure feed (which should hence be used only for the toolset package which doesn't exist in the default nuget feed). <?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<clear />
<add key="nuget" value="https://api.nuget.org/v3/index.json" />
<add key="dotnet-tools" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json" />
</packageSources>
</configuration>Alternatively, I think you could use Package Source Mapping to ensure only the toolset package is installed from the Azure feed. |
|
I confirm that the issue is still present in dotnet8-preview.5 and that it was fixed in both Package Source Mapping and Preview 6 from https://github.com/dotnet/installer#table. |
|
Just got the update and tested 17.6.3 after fixing some project settings for my case. It is working now. |
From my side, I can confirm that the issue with .NET 7 is resolved with SDK version 7.0.304. However, I cannot provide any insights regarding .NET 8 Preview 5. Regarding .NET 6, it seems that there are some changes that have not been backported, such as the one mentioned here: #8770. In my opinion, it would be better for people to create separate issues specifically for .NET 6 or .NET 8, as this particular issue is focused on the 7.0.302 SDK. |
|
Normally that would be true, in this case it looked like everyone had the issue until the update and now it's just .Net 8 Preview version, so it is probably a different issue at this point. |
I also confirm that this workaround works for my project and .NET 8 preview 5. Just have to remember to remove it on the next preview update :) |
and others
Is there an existing issue for this?
Describe the bug
Hello,
After updating the SDK to version 7.0.302, we encountered numerous errors in our MudBlazor project. One particular example is the ambiguous call issue shown in the screenshot below. It appears that the Razor parser has become more strict, and the unnecessary
@symbol may be causing the problem. However, I'm unsure how to resolve all the errors, such asThe attribute names could not be inferred from bind attribute 'bind-IsVisible'orMultiple components use the tag 'MudSwitch'.Could you provide some insight into their meaning?While I don't have a reproduction repository available, you can review the logs at the following link for further details:
GitHub Logs
If you clone the MudBlazor repository and compile it with the 7.0.302 SDK version, you'll have a better understanding of the overall situation.
NB! creating
global.jsonwhere you set previous SDK version does solve the problem, but this is not really a solution.It would be greatly appreciated if you could provide any information or documentation regarding the changes and how to address them. Are there any workarounds available? I'm also curious why a breaking change was introduced in the .NET 7 SDK rather than do them in .NET 8.
Thank you for your assistance.
Exceptions (if any)
Error list example
.NET Version
7.0.302
Anything else?
Post update 5/19/2023
Here are some solutions and workarounds for addressing certain errors and warnings:
Multiple components use the tag 'componentName'(RZ9985):See Blazor regression in 7.0.302 SDK #8718 (comment) for more information and avilable workaround.
The attribute names could not be inferred from bind attribute(RZ9991):See Blazor wasm: RZ9991 build error when updating from 7.0.203 to 7.0.302 sdk #8725 (comment) for possible workaround, another options it to try latest NET 8 preview SDK instead.
Found markup element with unexpected name 'componentName'. If this is intended to be a component, add a @using directive for its namespace(RZ10012):Try this workaround Blazor regression in 7.0.302 SDK #8718 (comment), another options it to try latest NET 8 preview SDK instead.
The type or namespace name '' could not be found in the global namespace (are you missing an assembly reference?)(CS0400):Try to specify full qualifier Blazor missing assembly reference with 7.0.302 #8729 (comment), another options it to try latest NET 8 preview SDK instead.
Cannot implicitly convert type 'Microsoft.AspNetCore.Components.ElementReference' to '[className]'(CS0029):No workaround available except trying the latest NET 8 preview sdk instead or downgrading the SDK to previous version.
Important Note: It is worth mentioning that Microsoft recommends work around the issues by pinning the 7.0.20xx SDK instead.
Downgrading SDK
One potential solution to address the issues caused by the new SDK version is to consider reverting to the previous SDK version: #8718 (comment).
It's important to note that if you are using containers, you should also ensure that the SDK version is changed accordingly. You may need to update the Dockerfile or related configuration files to specify the desired SDK version, as mentioned in this comment: #8718 (comment).
Additionally, don't forget to review other areas, such as GitHub workflows, or others CI/CD.
The text was updated successfully, but these errors were encountered: