Suggestion to use ConfigureAwait(false) is potentially dangerous

[Isaks (Isak Savo)]

1. Create a class library and add a user control (WPF)
2. Create a method that is async, returning a task, for example a button click event handler (see example below)
   • Test: Code runs fine, button click will change background color
3. Run SonarLint, with the S3216 rule enabled
   • It incorrectly warns that await should use .ConfigureAwait(false)
4. Add .ConfigureAwait(false) and run again. Application crash with InvalidOperationException

private async void Button_Clicked(object sender, RoutedEventArgs e)
{
	await Task.Delay(1);
	// Sonar wants me to change the above to this:
	//await Task.Delay(1).ConfigureAwait(false);
	Random r = new Random();
	Background = new SolidColorBrush(Color.FromRgb(
		(byte)r.Next(255),
		(byte)r.Next(255),
		(byte)r.Next(255)));
}

I have even marked the .csproj file to be of type WPF Project (<ProjectTypeGuid>{60DC8134-EBA5-43B8-BCC9-BB4BC16C2548}</ProjectTypeGuid>) but it didn’t matter.

Note: The same code in a WPF Application project (type .exe) does not have this behavior. Seems sonar is basing it on the code residing inside a .dll.

For now we have disable this rule completely, but it would be nice if sonarqube be smarter about this rule and correctly determine when it’s safe to use .ConfigureAwait(false) and when not to.

[Andrei_Epure]

Hi @Isaks , thanks for raising the point.

The implementation for this rule is quite simplistic - see TaskConfigureAwait.cs. And indeed it’s only analysing DLLs.

From your point of view, which would be the exceptions the rule should consider?

Thanks,
Andrei

[Isaks (Isak Savo)]

Ideally it should detect all cases of code where the code after await has thread affinity. Off the top of my head:

• Any code that interacts with WPF or Window Forms controls. This often include viewmodels (but not always)
• Asp.NET MVC controllers and supporting code, since they may need the current request

This is probably too complicated for your analyzer to figure out, so perhaps you need to rely on some opt-in attribute the developer can place on a class, method or assembly?

This is probably the reason why the CLR team did not make ConfigureAwait(false) the default behavior - it’s simply impossible to know when it is safe to use.

[Dmitry_Golovinov]

Hello @Isaks , first things first - thank you for using our product and providing a valuable feedback.

In your routine you can use another way to disable the rule not for the whole project, but for the particular subset of files with the help of editorconfig files.

Indeed, detecting all those kind of situations will be too complicated for a rule like this. Instead we were thinking about potentially disabling the rule for project, that reference Form Controls. But introducing such a kind of logic will also require a significant amount of work from us.

I’ve created a report for the code you’ve provided and you will be able to track the progress with the following link.