Repository navigation
Allow codeformatter to use analyzers from external DLLs - #217
Conversation
…n version should work
|
Hi @danquirk, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution! TTYL, DNFBOT; |
| { | ||
| // use Roslyn's existing simple loader, there're no special requirements for our usage | ||
| var loaderAssembly = Assembly.Load((typeof(CommandLineProject)).Assembly.FullName); | ||
| _analyzerAssemblyLoader = (IAnalyzerAssemblyLoader)Activator.CreateInstance(loaderAssembly.GetType("Microsoft.CodeAnalysis.SimpleAnalyzerAssemblyLoader")); |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
|
@danquirk, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR. |
…oslyn's via reflection
| typeof(OptimizeNamespaceImportsAnalyzer).Assembly | ||
| }; | ||
| // TODO: fix hardcoded path | ||
| private static string TestDLLDir = @"E:\src\codeformatter\src\Microsoft.DotNet.CodeFormatting.Tests\TestAnalyzers\"; |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
|
LGTM pending the testcase |
|
@danquirk Do you plan on addressing the TODO in this PR or a follow-up PR? If you are planning on doing a follow-up PR then we can merge this change in |
|
@basoundr unless you have an immediate need for it in its current form I think I'd prefer to just do the fixes in this PR and then have it all merged at once in a better state. I'll try to get to these other review comments shortly. |
|
Our team is having a FxCop day(All our team members work on just the analyzers-related things on this day) this Thursday. We were hoping that, if you could have this change merged in and have CodeFormatter run on repos like CoreFx & others, which are amazing testbeds for analyzers, then we might hit some bugs in the Analyzers and have those bugs addressed during our FxCop day. Is this something that would fit into your schedule? |
|
Yeah, that seems doable. |
|
Awesome! I will merge this PR in and I will create an issue with the TODO mentioned in the PR |
No corresponding issue for this as far as I know but I can create one if you'd like. I've talked to @srivatsn about this a bit in generalities.
The basic idea is to pass codeformatter a DLL which contains some analyzers and it will run those analyzer(s) against the given target(s). The targets can be project path or a file listing project path and the analyzers can be a path to the DLL or a file listing paths to multiple DLLs. A new
analyzecommand is added to do only analysis of the target without applying any corresponding code fixes from the analyzers.I had to upgrade to newer versions of Roslyn and System.Reflection.Metadata to support the latest analyzers from Roslyn and 3rd parties. I had tried to add new analyzers just using MEF rather than IAnalyzerFileReference (see this branch) which seemed like it should be cleaner but didn't seem to work for certain analyzers. There's some unfortunate reflection into Roslyn for internal types that may not be the fastest/best solution long term.
TODO: