-
Notifications
You must be signed in to change notification settings - Fork 4
Home
Welcome to the Fabric.SharedSettings wiki!
This is where we will record our knowledge of various Code Analysis errors, StyleCop warnings, and ReSharper suggestions, with advice on how to deal with them based on our experience.
Depending on the execution environment, Tasks may try to get back onto their originating SynchronizationContext before executing their continuations. When they do, any attempt to block the current thread to synchronously await the task's continuation (e.g. via .Wait()
or .Result
) will result in deadlock: the task cannot continue without being on the original synchronization context, and the original synchronization context won't be released until the task's continuation completed.
Because we typically have no control over what environment a class library may be accessed from, our ClassLibrary ruleset will default to treating this issue as an Error, and it is recommended that all Tasks be awaited via ConfigureAwait(false)
. You may wish to use a Fody Addin to automatically inject ConfigureAwait(false)
before each await
at compile-time: in that case, this rule can be set to "None" for your Project.
In Web Applications and WPF/Forms-type applications, it's difficult to know when ConfigureAwait
is necessary without understanding your code base, so Catalyst.MostRules.Error.ruleset
sets this rule's severity level to "None" by default. If you're consistently using async/await
rather than .Wait()
or .Result
throughout your application, you should probably not bother changing this. However, if your application has some async
logic that gets translated to synchronous logic via calls to .Wait()
or .Result
, consider enabling this rule. The general rule of thumb is to use ConfigureAwait(false)
whenever you are certain that the remainder of the current method is not going to need the SynchronizationContext, ConfigureAwait(true)
when it might need the SynchronizationContext (e.g. for things like HttpContext.Current
), and you should never block on any Task that ever passed through a ConfigureAwait(true)
.
If your assembly is intended to be reused as a library, then put the following attribute in your project's Properties/AssemblyInfo.cs
file:
[assembly: CLSCompliant(true)]
Otherwise, use GlobalSuppressions.cs to suppress this message, just for this project:
[assembly:
SuppressMessage(
"Microsoft.Design",
"CA1014:MarkAssembliesWithClsCompliant",
Justification = "This project is not consumed as a library.")]