You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had a class whose methods were all "Shared", so it could be a Module instead. After changing it to Module, the "Shared" keyword now generates a compile error BC30433. Now, I've to manually go and delete the Shared keyword one by one. It'd be nice if a codefix is offered to fix all and remove the "Shared" keyword easily. The codefix should be straight forward, just remove any "Shared" keyword that has reported BC30433.
There is already a diagnostic CA1052 when all functions are shared, so you could do the whole thing. Change Class to Module, and remove the Shared. Or do you just want a CodeFix for BC30433?
I haven't checked, but I think CA1052 doesn't have a code fix as well. So, now there are two possible places for the fixer. But I personally would prefer BC30433 to have the codefix. As it'll serve more developers (developers who doesn't use FxCop NuGet package)
@Youssef1313 I tried to prototype a fix for CA1052 but for testing I need the Analyzer that produces it. Is there a way to use a NuGet Analyzer in a test or does that even make sense inside Roslyn? CA1052 is produced by FxCop NuGet package would it need to be part of Roslyn or should the fix go in there?
Roslyn should only have code fixes for analyzer diagnostics produced by compiler or IDE. For CA1051 code fix, please submit PR to Roslyn-analyzers repo. If fixing compiler diagnostic mentioned here, you can submit a PR to Roslyn.
@Youssef1313 BC30433 should be fixed in Roslyn and I was not planning on doing anything with that. If someone wants to work on it I can share source of a working standalone CodeFix but it don't have integration with Roslyn. For CA1052 I will look at Roslyn-analyzers repo but it will take me some time to understand its support for CodeFixes written in VB.
Activity
CyrusNajmabadi commentedon Jun 15, 2020
I believe we would take a community PR on tihs.
paul1956 commentedon Jun 15, 2020
There is already a diagnostic CA1052 when all functions are shared, so you could do the whole thing. Change Class to Module, and remove the Shared. Or do you just want a CodeFix for BC30433?
Youssef1313 commentedon Jun 15, 2020
I haven't checked, but I think CA1052 doesn't have a code fix as well. So, now there are two possible places for the fixer. But I personally would prefer BC30433 to have the codefix. As it'll serve more developers (developers who doesn't use FxCop NuGet package)
paul1956 commentedon Jun 18, 2020
@Youssef1313 I tried to prototype a fix for CA1052 but for testing I need the Analyzer that produces it. Is there a way to use a NuGet Analyzer in a test or does that even make sense inside Roslyn? CA1052 is produced by FxCop NuGet package would it need to be part of Roslyn or should the fix go in there?
Youssef1313 commentedon Jun 19, 2020
My personal opinion would be to make the code fix in roslyn, not roslyn-analyzers. You can write the codefix in Roslyn and make a PR.
paul1956 commentedon Jun 20, 2020
@jinujoseph, @Youssef1313 I will give fixing CA1052
mavasani commentedon Jun 22, 2020
Roslyn should only have code fixes for analyzer diagnostics produced by compiler or IDE. For CA1051 code fix, please submit PR to Roslyn-analyzers repo. If fixing compiler diagnostic mentioned here, you can submit a PR to Roslyn.
Youssef1313 commentedon Jun 22, 2020
I believe the codefix should be for BC30433, not CA1052
paul1956 commentedon Jun 23, 2020
@Youssef1313 BC30433 should be fixed in Roslyn and I was not planning on doing anything with that. If someone wants to work on it I can share source of a working standalone CodeFix but it don't have integration with Roslyn. For CA1052 I will look at Roslyn-analyzers repo but it will take me some time to understand its support for CodeFixes written in VB.