In the dashboard we have a few cases where we need to generate CSS directly from C# code. We do this both in .razor files and .razor.cs files and using both ToString() and string interpolation. All of those scenarios by default use the current culture. But in CSS it need to be invariant culture (specifically to prevent commas being used instead of decimal point as seen in #841).
We already have CA1305 enabled as a warning for .cs files.
First, we should look at whether this can be enabled for .razor files as well to force us to think about it when using it in .razor files.
Second, we should look at what we can do about string interpolation. I don't think that analyzer does anything for string interpolation (could be wrong) in .cs or .razor files. But this is increasingly what we're using as opposed to the calls caught by CA1305. So we need some way to ensure we're consistent about it and avoid similar, hard to track down bugs.
In the dashboard we have a few cases where we need to generate CSS directly from C# code. We do this both in .razor files and .razor.cs files and using both ToString() and string interpolation. All of those scenarios by default use the current culture. But in CSS it need to be invariant culture (specifically to prevent commas being used instead of decimal point as seen in #841).
We already have CA1305 enabled as a warning for .cs files.
First, we should look at whether this can be enabled for .razor files as well to force us to think about it when using it in .razor files.
Second, we should look at what we can do about string interpolation. I don't think that analyzer does anything for string interpolation (could be wrong) in .cs or .razor files. But this is increasingly what we're using as opposed to the calls caught by CA1305. So we need some way to ensure we're consistent about it and avoid similar, hard to track down bugs.