I'm writing a code analyzer/fixer
Statements:
- The (most)analyzer/s is/are only working for specific types so it needs to know the typename at least.
- I only see examples on the internet where the typename is given as a string, and so if somebody refactor the library code and rename the type it'll broke the analyzer.
- I wanted to make the analyzer as a standalone assembly, not just creating an analyzer class inside the library code.
Question:
You could make things safer by directly reference the analyzed type inside the analyzer assembly instead of referring to it as a string right?
However I can't refer the library assembly from the analyzer, because it'll lead to circular dependencies
=> A third assembly required that contains the analyzed typed. Isn't this cause "management overhead"?
Any thoughts, and why i don't see examples that are directly referring to the analyzed type instead of referring to it as a string?
2 Replies
feel free to move your question to #roslyn as i think it'll get more eyes there, but as someone who's been working on analyzers myself and had this exact question:
the suggestion is always to refer to the type as a plain string metadata name. you're not supposed to reference the assembly containing the target types in the analyzer.
if you're concerned about things breaking, i highly suggest writing unit tests for your analyzer that you should run before you push any changes. that way, even if you forget to change the metadata name string, you'll be reminded of that when you run your tests
thanks