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/ConstantStringshows that if the offending string is a constant, then we can't fix it ... and I think that is perfectly reasonable. The problem is thatFileSystemPathsCodeFixProvideris still registering aCodeActionclaiming to fix it and thatCodeActiondoesn't actually do anything. Normally, this would trigger a failure in the BulkUpdate test, butWellKnownFixAllProviders.BatchFixer.GetFixAsyncseems 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"CodeActionand that causes the test to correctly detect that fixing the batch did not reduce the number of batches.Fixing this means that
RegisterCodeFixesAsyncshould 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