Add PredefinedCode{Fix,Refactor}ProviderNames to CodeAction.CustomTags to identify analyzers\fixers for telemetry #4919
Comments
|
right now there is nothing that can be used to distinguish code actions except type name. unless we want to add a public field for it, not sure what we can do. |
|
we need design change. there is no info we can use right now. moving it out of update 1 |
|
one idea from @mavasani we can log fixer's type name + equivalence key (if there is one) this actually change semantic of what we log - basically rather than which code action, it will log which fixer has invoked. also, if equivalence key is different for same code action based on which context, then what we log is not which codeaction but codeaction + context. so, this does change semantic slightly, but we can get rid of those wrapper type just to get type name of code action. |
|
@heejaechang if we can report it as a string and use the actual name, I am 100% on board with any changes. fyi @CyrusNajmabadi |
|
We were meant to file a bug on that, but I'd suggest you do so as partner team request weighs more. |
|
@olegtk what is the path to file a bug? |
|
DevDiv\VS Platform\VS IDE\Editor\LightBulb |
|
@heejaechang @olegtk Is this implemented? Can you please share the external bug ID? We would like to clean up the fixers in roslyn-analyzers repo once this is done. |
|
@heejaechang where can the logs for the fixers be found? |
|
Re-purposing this issue to cover the discussed solution (Add |
…ted through CodeAction.Create factory methods Fixes dotnet#4919 Currently, we always use the CodeAction's full type name to generate the telemetry ID to log for applied code actions. This is reasonable for special CodeActions that sub-type the CodeAction type and have custom logic. However, majority of fixers and refactorings do not need special CodeAction sub-type and can/should use the CodeAction.Create factory methods to create the code actions to register. Until now, these providers were forced to create a dummy nested type (generally named MyCodeAction) and use it to allow telemetry to capture the outer type's full type name. With this change, we now keep track of whether a CodeAction was created with a factory method or not. If it was created with a factory method, then we use the registering fixer/refactoring provider's full type name for telemetry. Otherwise, we use the CodeAction's full type name. Additionally, we also append the EquivalenceKey in the telemetry ID in both the cases, which should allow multiple code actions registered by the same fixer/refactoring to be differentiated. NOTE: I will create a follow-up PRs in both Roslyn and Roslyn-Analyzers repos to delete all the stub MyCodeAction types once this goes in.
…ted through CodeAction.Create factory methods Fixes dotnet#4919 Currently, we always use the CodeAction's full type name to generate the telemetry ID to log for applied code actions. This is reasonable for special CodeActions that sub-type the CodeAction type and have custom logic. However, majority of fixers and refactorings do not need special CodeAction sub-type and can/should use the CodeAction.Create factory methods to create the code actions to register. Until now, these providers were forced to create a dummy nested type (generally named MyCodeAction) and use it to allow telemetry to capture the outer type's full type name. With this change, we now keep track of whether a CodeAction was created with a factory method or not. If it was created with a factory method, then we use the registering fixer/refactoring provider's full type name for telemetry. Otherwise, we use the CodeAction's full type name. Additionally, we also append the EquivalenceKey in the telemetry ID in both the cases, which should allow multiple code actions registered by the same fixer/refactoring to be differentiated. NOTE: I will create a follow-up PRs in both Roslyn and Roslyn-Analyzers repos to delete all the stub MyCodeAction types once this goes in.
We currently create a separate code action for every fixer to identify the fixer for telemetry. We need a different mechanism so that people can just use CodeAction.Create
The text was updated successfully, but these errors were encountered: