The sample FileSystemPathsAnalyzer/ConstantString shows that if the offending string is a constant, then we can't fix it ... and I think that is perfectly reasonable. The problem is that FileSystemPathsCodeFixProvider is still registering a CodeAction claiming to fix it and that CodeAction doesn't actually do anything. Normally, this would trigger a failure in the BulkUpdate test, but WellKnownFixAllProviders.BatchFixer.GetFixAsync seems to return null when no changes are made and that causes CodeFixer to give up. If I update the unit tests to use Roslyn 4.0.1, then GetFixAsync starts returning an "empty" CodeAction and that causes the test to correctly detect that fixing the batch did not reduce the number of batches.
The sample
FileSystemPathsAnalyzer/ConstantString
shows that if the offending string is a constant, then we can't fix it ... and I think that is perfectly reasonable. The problem is thatFileSystemPathsCodeFixProvider
is still registering aCodeAction
claiming to fix it and thatCodeAction
doesn't actually do anything. Normally, this would trigger a failure in the BulkUpdate test, butWellKnownFixAllProviders.BatchFixer.GetFixAsync
seems to return null when no changes are made and that causes CodeFixer to give up. If I update the unit tests to use Roslyn 4.0.1, then GetFixAsync starts returning an "empty"CodeAction
and that causes the test to correctly detect that fixing the batch did not reduce the number of batches.Fixing this means that
RegisterCodeFixesAsync
should detect if there is something that can be fixed before registering a code fix. I expect that much of the leg-work would have already been done by the analyzer, so you could avoid the duplicated effort by adding a property to the diagnostic with this information, then the CodeFixProvider only needs to check for the property rather than re-analyzing the code.WI00603506