-
Notifications
You must be signed in to change notification settings - Fork 462
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CA1303 is more irritating than helpful #2933
Comments
@mavasani Do you have an opinion on this? I tend to agree with the various comment, I think we should report on parameters marked the localizable attribute and also on some well-known invocations. We could think of having a user-option to enable more parameters/invocations. |
@Evangelink Lets start with the following:
|
I'm struggling to understand my options for configuring this warning. Everywhere in my code where I throw an exception with a string literal for the message, I get this warning. Is there a way to configure CA1303 to suppress this construct (code that calls a constructor on a class that inherits from system.Exception)? |
Also, an editorial cleanup. The documentation language reads:
The syntax should be corrected to read:
|
I have a project in ASP .NET Core 3.1 where i added the nuget package This is my
I have a class
When calling the logger with a string, I get the CA1303 warning. I tried with true/false, I tried also adding Am I misunderstanding this functionality and configuring wrong or is there possible bug here? |
It's a bug already fixed in version 3.3.0-beta1.20261.6. Source: MVC Core LogCritical etc. messages should not trigger CA1303 #3254 |
Analyzer package
Microsoft.NetCore.Analyzers
Package Version
v2.9.6 (Latest)
Diagnostic ID
CA1303
Repro steps
string text
as a parameter.Expected behavior
Should trigger only on developer-specified parameter names, or only those tagged with the Localizable attribute. As is, it's more irritating than helpful.
Actual behavior
Triggers every time, whether you want it to or not, and is not configurable in any way without turning off the entire rule.
This was previously mentioned here but the user never followed up on it. Two or three separate rules would be a good start, and being able to configure the parameter name list would be extremely helpful. The System.Exception customization in #2602 doesn't really do anything when you're working with (or designing) libraries that modify language-invariant resources.
The use of the name "text" as a parameter is ubiquitous in libraries that have nothing to do with UI or other language-specific resources. If, say, I were programatically generating code and the program had an AddText(string text) method, I would certainly never want to localize "foreach" to "pourchaque"! Similarly, as a developer, I don't want to be limited to having to design AddText(string txtCuzRoslynAnalyzersSaysNoT_e_x_t) functions, just to be sure I don't use the word "text" in a function where that's the most logical name, and don't hit on any names that might get added to the list later on.
It's a well-intentioned rule, just not a very practical one as it stands now.
The text was updated successfully, but these errors were encountered: