I'm trying to support built-in Roslyn code fixers in my IDE (QueryStorm). I have had success with some fixers, mostly the ones that don't require a user interface, e.g. ProjectSymbolReferenceCodeAction which can add missing using namespace ... declarations.
I'm having trouble supporting other fixers due to the necessary types being internal. For example, the CodeActionWithNestedActions type is internal, so I have to use reflection to get the NestedCodeActions if I want to offer them in my IDE. While inconvenient, this is still doable.
However, other situations don't seem to have viable workarounds. For example, the Microsoft.CodeAnalysis.GenerateEqualsAndGetHashCodeFromMembers fixer requires a service called IPickMembersService to collect additional information from the user. The problem is that this interface is internal so I can't implement it.
Does this mean I can't use this fixer and others like it or am I going about this the wrong way? If I can't use these fixers, what would be a good way to determine which fixers I can use and which I can't?
Does this mean I can't use this fixer and others like it
Those interfaces are internal so we really don't expect third parties to be implementing them. You could file a bug against Roslyn to figure out a plan here, but I admit I'm not sure which direction we'd do. (We've had some similar conversations around VS Code too, since we don't support these fixes in VS Code since our existing UI isn't cross-platform.)
Note that some of those fixes too have options that will show UI, and some that won't. If you're seeing bugs where we're not gracefully detecting the lack of the service and throwing exceptions, do file bugs or send PRs.
or am I going about this the wrong way?
It's hard to say if you're also doing other wrong things; feel free to open a conversation on GitHub with the issues you're running into, and we can comment on whether that's because you did take a wrong path somewhere, or you're just doing something we never anticipated.