BL0007: Component parameters should be auto property ignores .editoronfig on linux

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Having a component which violates the new BL0007 rule will lead to an build on linux machine (github action) even though the analyzers severity is set to None in a .editorconfig. This seems only to happen on a linux machine.

Also in the latest nightly builds we can reproduce this issue.

Example code from here: https://github.com/bUnit-dev/bUnit/pull/672/commits/54dffbf798da858d5230eb82a3f40f471af6af6a And here the failing build result for that specific commit: https://github.com/bUnit-dev/bUnit/runs/5837646463?check_suite_focus=true

We also could reproduce this with the latest version (7.0.0-preview.3.22175.4 - nightly docker sdk builds) see here: https://github.com/linkdotnet/bUnit/runs/5851324603?check_suite_focus=true#step:6:12

Expected Behavior

Should not be shown as warning / error. Only the following snippet will “remove” the error

#pragma warning disable BL0007
...
#pragma warning restore BL0007

Steps To Reproduce

See bug description

Exceptions (if any)

No response

.NET Version

7.0.100-preview.2.22153.17

Anything else?

No response

[linkdotnet]

I do think there are very valid cases, especially two-way binding aka @bind-Value:

[Parameter]
public string Value 
{ 
  get => _value; 
  set
  {
    if (value != _value)
    {
      _value = value;
      ValueChanged.InvokeAsync(value);
    }
  } 
}

[Parameter]
public EventCallback<string> ValueChanged { get; set; }

BL0007 would now suggest moving the ValueChanged.InvokeAsync outside, so I have to duplicate that code where ever that event would have triggered.

[szalapski]

Ran into this today. I have three cases:

• One Parameter is used as a facade into the “real” backing property which is called from the Parameter’s setter
• One parses nulls and empty strings to normalize the user input
• One has getter and setter than exposes a string as an integer though the underlying value is a string. The getter/setter handle the parsing and the cases where that doesn’t work.

In fact, this is why we have properties in the first place–to allow abstractions on getting and setting. Otherwise, why not bind to plain old fields?

I like this warning so as to encourage use of @bind:after, but I wonder if there is a more nuanced way.