Compiler errors point to the beginning a .razor file, not to the actual error

This issue has been moved from a ticket on Developer Community.

[severity:It's more difficult to complete my work] When editing Blazor components, if there is an error, the report in the Error List window always shows line1 of the .razor file, instead of the actual line on which the error appears. Usually, the actual line in the editor doesn't show an error, making it almost impossible to know what is wrong.

The attached screenshot shows an example. The actual error was on line 160 in that file, but nothing was shown in the editor.

This makes Blazor development extremely difficult.

Original Comments

Feedback Bot on 12/29/2020, 10:50 PM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Feedback Bot on 1/4/2021, 10:02 AM:

Thank you for sharing your feedback! Our teams prioritize action on product issues with broad customer impact. See details at: https://docs.microsoft.com/en-us/visualstudio/ide/report-a-problem?view=vs-2019#faq. In case you need answers to common questions or need assisted support, be sure to use https://visualstudio.microsoft.com/vs/support/. We’ll keep you posted on any updates to this feedback.

Taylor Mullen [MSFT] on 1/4/2021, 10:42 AM:

Unfortunately your provided screenshot is not coming through on our end. Would you mind providing one of the following:

A repro app for us to easily investigate
Another screenshot (sorry!)
The error message

Why do we ask for more info?
We try to reproduce all issues reported with the information provided in the description and comments. When we can’t reproduce the issue, we ask you for more information so we can resolve the issue as quickly and efficiently as possible.
In our guidelines, you can get tips on how to provide clear and simple reproducible steps.

mryossu on 1/5/2021, 00:11 PM:

Please find a screenshot

Thanks

VS error panel.png

Taylor Mullen [MSFT] on 1/11/2021, 10:45 AM:

Oh interesting, do you happen to know which line it does correlate to? If so would it be possible to provide that line?

Feedback Bot on 1/19/2021, 07:24 PM:

We will close this report in 14 days because we don’t have enough information to investigate further. To keep the problem open, please provide the requested details.

mryossu on 1/21/2021, 00:58 PM:

Sorry, never got a notification of your reply.

I’ve just had this problem again, and so can give you some repro steps. Create a new Blazor project. Add a reference to the LanguageExt Nuget package. The issue is nothing to do with that package, but it just happens that the most recent time I’ve seen the issue is with code that uses it.

In case you aren’t familiar with the package, it provides support for functional programming in C#. The specific feature I’m using here is Option, which is a way of specifying that data may or may not be present, ie if you look for a customer with id 42, and there isn’t one, you get a None. If there is one, you get an Some. This isn’t actually relevant to the problem, but that should help you understand the code.

Add the following line to _Imports.razor…

@using LanguageExt

Add a Blazor component named OptionBlazor.razor, and use the following code…

@using LanguageExt
@typeparam T

@Value.Match(x => Some(x), None)

@code {
  [Parameter]
  public Option Value { get; set; }

  [Parameter]
  public RenderFragment Some { get; set; }

  [Parameter]
  public RenderFragment None { get; set; }
}

The idea here is that you pass in an Option<T>, and the component displays one of two render fragments, depending on whether the Option was a Some or a None.

Now add a component to test this. I named mine OptionSample…

@page "/OptionSample"
<h3>Option sample</h3>

<h3>Some:</h3>

  @customer.Name (id: @customer.id) is @customer.Age years old
  No customer

<h3>None:</h3>

  @customer.Name (id: @customer.id) is @customer.Age years old
  No customer

@code {

  private readonly Option _some = new Customer(1, "Jim Spriggs", 42);
  private readonly Option _none = Option.None;

  private record Customer(int id, string Name, int Age);

}

If you now try to build, you’ll see that you get four identical errors in the Errors panel…

Error The type arguments for method ‘TypeInference.CreateOptionBlazor_1<T>(RenderTreeBuilder, int, int, object, int, RenderFragment<T>, int, RenderFragment)’ cannot be inferred from the usage. Try specifying the type arguments explicitly. Pixata.Blazor.Sample C:\Users\AY Silver\Pixata\Pixata Utilities\Pixata.Utilities\Pixata.Blazor.Sample\Pages\OptionSample.razor 1 CS0411 Active

You get two errors in OptionSample.razor, both marked as being on line 1, and two errors in OptionSample.razor.g.cs, on lines 104 and 102 (your line numbers may be different).

The editor does not show any errors at all, and as the error panel reports them as being on line 1, it’s impossible to tell what caused the error. In this simple example it’s obviously an issue with the usage of OptionBlazor, although I don’t know what.

The offending code line in the .g.cs file is…

__Blazor.Pixata.Blazor.Sample.Pages.OptionSample.TypeInference.CreateOptionBlazor_0(__builder, 2, 3, "_some", 4, (customer) => (__builder2) => {

…with the other being almost identical.

Does that help? Thanks

mryossu on 1/21/2021, 01:10 PM:

P.S. I just realised what the problem was with the code sample. In the OptionBlazor component, the parameter was named Value, whereas in the OptionSample where I used it, I mistakenly typed Data instead.

However, the main point still remains, that the error message shown pointed to line 1 of the file, and not to the line where the error occurred.

mryossu on 2/2/2021, 02:24 PM:

Any comments?

Taylor Mullen [MSFT] on 2/3/2021, 11:14 AM:

Thanks for the repro steps mryossu. I tried reproducing but I’m still not able to reproduce the issue. After fixing the “Customer” compile error I still am left with valid line numbers. Would you mind zipping up a project that shows the behavior you’re referring to?

mryossu on 2/8/2021, 02:34 PM:

Hello again. Sorry for the further delay, but as I don’t get any notifications of your reply, I don’t know you have. I just came back here to see if there was a reply, as it’s happening yet again, and I’ve wasted about an hour trying to work out where there is an error in my code. VS just shows it on line 1 of the .razor file, but the editor doesn’t show any errors.

Anyway, I zipped up the sample I mentioned earlier, and have attached it. As it is now, it compiles fine, but if you look at Index.razor, and change…

…to…

…you’ll see the error.

As I said, I get this sort of error a lot, so it’s nothing to do with this specific case, this just happened to be the latest time I saw it when I posted. It happens a lot, and it’s almost impossible to work out where the error is.

Thanks
LineNumberError.zip

Taylor Mullen [MSFT] on 2/8/2021, 03:32 PM:

Oh shoot, your content didn’t come through! COuld you try providing the edits you mentioned in a different fashion?

mryossu on 2/9/2021, 06:14 AM:

Bizarre about the code. Looking at my earlier post, anything with angle brackets was mangled as well.

Anyway, the code change was simple enough. Ignoring angle brackets, line 6 of Index.razor looks like this…

OptionBlazor Value="@_some" Context="customer"

That is correct. However, if you change the Value attribute to be Data (which is what it was originally called), then you get a compiler error, as there isn’t a Data attribute. However, the error window shows the error as being on line 1 of the file. This makes it extremely hard to debug. It was made harder by the error message itself being quite obscure.

That should allow you to see the problem in the sample I set up. As it happens, I found an even easier example last night. I am using a Telerik Window (not relevant to know about the component), and wanted to set the visibility to be based on a variable. I copied their sample, which included the following bit of code…

@bind-Visible=@WindowVisible

As I wasn’t using a bool variable to set visibility, I changed this to…

@bind-Visible="@(_newTerm.Start != DateTime.MinValue)"

This gave a compiler error, which the Error window again reported on line 1.

I realised eventually that the above is wrong, as you can’t do two-way binding with an expression like that, but the inaccurate error message wasted a lot of my time, both because of the non-obvious message, and more because of the fact it pointed to line 1 of the file.

I find this problem happens a lot, and it makes working with Blazor quite difficult. Hopefully you can see the issue now.

Thanks again

Taylor Mullen [MSFT] on 2/9/2021, 10:37 AM:

I can reproduce consistently! Thank you mryossu for all of the back and forth, we’ll triage this for investigation.

Feedback Bot on 2/9/2021, 10:41 AM:

Feedback Bot on 4/13/2021, 03:52 AM:

I detected that this issue hasn’t received a lot of activity, votes, or comments in the past 90 days. Based on this, the issues severity and affected area, it’s my experience that this issue is unlikely to get fixed. To improve the situation, consider following best practices for quality problem reports, and giving us more details on how this issue is impacting you.

mryossu on 4/13/2021, 05:48 AM:

The reason there hasn’t been any activity is because we are waiting for you to do something about it.

I have already given you all the details I can. If you think there is something else I can tell you, please let me know what it is.

More to the point, please DO NOT just ignore an issue, then assume that the fact I’m not badgering you about it means it’s OK to ignore it further. This is a major issue, and one that affects my development significantly.

To summarise, it is almost impossible to find out the source of a problem when the error messages do not tell you where the error occurred. As you can see from the details I supplied, the error messages often point to the first line of a file, when that is clearly not the source of the error.

THIS NEEDS FIXING, NOT IGNORING!

Taylor Mullen [MSFT] on 4/13/2021, 09:48 AM:

mryossu apologies for the bulk comment add. We agree it’s an important issue; turns out it’s quite complex to solve though. We’re working internally to determine the best route forward.

mryossu on 10/26/2021, 07:19 AM:

Taylor Mullen [MSFT] Any news? It’s been over 5 months since your last reply.

Thanks

Taylor Mullen [MSFT] on 10/28/2021, 11:52 AM:

5 months is definitely a long time. Apologies! We’ve been weighing this work with other issues in our catalog and it hasn’t made the cut yet. The current state is that we’re looking at ways from the Razor compiler to address this issue.

Original Solutions

(no solutions)

dotnet / razor