We Keep Coding

Flaky execution of Code Analysis

I'm trying to have Code Analysis going for my .NET Standard 2.0 class library. As described here, I've added a reference to Microsoft.CodeAnalysis.FxCopAnalyzers. At the beginning, everything looked good and I started getting CA* warnings when building the project. However, after a while, these warnings disappeared although I hadn't touched the code.
Only after closing VS 2017, deleting all bin directories, restarting VS 2017, I started getting back the CA* warnings. However, this doesn't seem to be the recipe to get them back: in my CI environment, the same thing happened. I lost the warnings after an unrelated commit and I still didn't manage to bring them back although I've cleaned the checkout directory completely.
I wonder what could be the reason that at moments the Code Analysis stops working. Unfortunately, I haven't figured out a way to reproduce this - thus my question.
As a matter of fact, I'm eager to understand why adding a NuGet to a project can modify the outcome of the compilation process at all. How does that magic work? Any pointers are welcome.

As to how Roslyn Analyzers are loaded from NuGet
The new C# and VB compilers are based on Roslyn. Roslyn is an extensible compiler framework where a number of analyzers can run at different stages of the compilation process.
MsBuild will pass the analyzers references from the project file to the call to the Roslyn compiler, which will load these in turn and will execute them after the sources have been parsed and interpreted.
The NuGet packages have special metadata that ensures that these analyzers are added as a special type of reference to the MsBuild project file so that MsBuild can pass these along to the compiler.
As to why the analyzers sometimes fail
This is hard to say. Some metadata of projects is stored. Setting the options to clear the workspace/working directory and start afresh may fix this. Setting the build.clean variable to all should help with that. Deleting the bin, obj and .vs folder as well as the packages folder and performing a nuget restore + build should bring you back into a usable state.
The new FxCop analyzer project still isn't complete and is still being updated. A bug in the analyzer infrastructure can cause the analysis to fail. Unfortunately, this is generally very hard to debug. Turning off rules one by one may help you find the culprit.
There seems to be an option built into Roslyn to enable ETW Logging, which should give you a lot more details, but this isn't very well documented.
In Visual Studio there is another thing that can break the analyzers, Visual Studio Extensions can load analyzers as well, which Visual Studio will then inject into the build process. These extensions are not part of your project and thus won't show up in source control in any way. Any recently updated extension could thus also be the culprit. Setting the MsBuild verbosity level to Diagnostics should show you which analyzers are passed to csc, which should help you figure out where your problem may be coming from.

Analysis is switched off in re-sharper

I am getting an error says Analysis is switched off in one of the file in solution. I am not sure why re-sharper is not considering this file alone.
Please let me know, in case somebody have solution for the same. How to switch on analysis in re-sharper for one file alone?

There are a number of reasons for analysis being switched off in ReSharper. One is that the file is source, added by a NuGet package. This isn't your code, so won't necessarily be to your standards, so it's not fair to flag issues such as naming standard violations in this codebase. Another reason is that the file is a generated file, or contains generated regions (such as Windows Forms designer files). You can configure this in ReSharper → Options → Generated Code. Finally, there is another settings page: ReSharper → Options → Third-party Code, which allows disabling just analysis, or analysis AND indexing in certain code.

How does resharper recognise what files to include for its intellisense?

It is a well known issue with Resharper that it fails to recognize generated C# files using Custom Tasks (making intellisense fail). Does anyone know how to fix this without adding the files to the project?
(BTW, including the generated files in the project or creating a separate assembly and other such flawed suggestions are totally out of the question).
Can we write a Resharper plugin for this? We have a fairly large number of developers that cannot use Resharper, so this would well be worth the effort.
Can we somehow add the obj/*.g.cs files to
Resharpers non msbuild based csproj parser (lurking somewhere within Resharper)?
Is the method used by Resharper on how to resolve the list of .cs files to include documented somewhere?
As this issue is experienced and reported again and again for years, surely there must be someone who has cracked it by now?

I found an extension for Resharper: ReSharper.ExternalCode.
Tip for Antlr: add obj\Debug in Resharper -> Code Inspection -> External Code and reload solution.
It's works for me.

C# Interface Debug Information not linked to sources

I'm trying to re-jig the layout of a very large solution which has become impossibly hard (and s l o w) to work with. My plan is to create a number of solutions containing related projects, and then use binary references where necessary to link to libraries produced by the other solutions.
The thing we rely on to make this usable is Resharper's Navigate to External Sources functionality, so we can easily browse the source of the projects we are referencing from other solutions. Quite why VS can't do this out of the box is beyond me.
This is all working very nicely for classes with implementation. However, for C# interfaces and classes containing only auto-implemented properties, Resharper isn't able to browse to the sources, and falls back to cruddy metadata viewer.
I used srctool.exe, which comes with the Symbol Server tools in MS Debugging Tools For Windows, to browse the sources listed in the .pdb file, and it's clear that the sources for these interfaces and empty(ish) classes are not referenced in the pdb file. If I switch the auto-implemented properties to those with backing fields, then the source link appears in the pdb.
I'm guessing the sources are excluded because there are no places you could set breakpoints on interfaces and auto-implemented properties.
I'm wondering, though, if there is some exotic compiler option or workaround we can employ to force the PDB file to include references to the source of C# interfaces.
Thanks,
Mark

The question doesn't have enough detail. Shooting off the hip, I'd guess that you tackled the problems with the slow massive solution by converting project references to assembly references. And used the Release build of those projects as the reference.
And yes, that stumps any tool that tries to find source code files from the PDB. The release build of a .NET project uses a stripped version of the PDB, all the source code file and line number info has been removed from it. That's a pretty normal thing to do with real release builds. Release built code normally is optimized. That causes code to be re-ordered, no longer matching the logical position of the code in the source file. Any info you get from the source+line PDB info now tends to get between harmful and useless, you start looking in the wrong place for a problem.
That is however not a concern for IDE tooling or while debugging your app. The optimizer is automatically disabled in a case like this. Actually a configuration item in VS: Tools + Options, Debugging, General, "Suppress JIT optimization on module load" option. Turned on by default.
Clearly any tooling that uses the PDB is going to catatonic when they don't have a chance to find source files. The fix is to go back to the original project, select the Release configuration again and change a setting: Project + Properties, Build tab, scroll down, Advanced button. Change the "Debug info" combo from "pdb-only" to "full". Rebuild the project.
Should fix your problem. Also revives the debugger, you can step into the source code again.
Don't move files around too much btw, you might stump the chumps again. At least keep the PDB with the DLL in the same directory. If the source code is no longer present in the same directory but you checked it out again in another one then you have to tell the IDE about it. Right-click the solution, Properties, Debug Source Files setting.

Refactor "using" directives over an entire codebase?

One of the things I love about Visual Studio 2008 is the ability to refactor and reorganize the "using" directives in source code files (this may have been in 2005 as well, I don't remember).
Specifically, I'm talking about how you can have it both reorganize the directives to be alphabetical (though with the core FCL libraries floating to the top) and removing any directives which don't need to be there (either never used or no longer used).
Is there any way to automate this refactoring (the sorting and trimming) across an entire old codebase? Either through all of the files in a solution or across multiple solution files.

I believe you can do it solution wide using Power Commands
From PowerCommands Documentation:
Remove and Sort Usings
This command removes and sort using statements for all classes given a project. It is useful, for example, in removing or organizing the using statements generated by a wizard. This command can be executed from a solution node or a single project node.

ReSharper is a (commercial) Visual Studio plugin that has a "Code Cleanup" utility than can be run at a solution-wide level. The utility detects and removes unreferenced using statements, and performs other useful maintenance. I am unsure if it provides functionality to sort them, however.

Use PowerCommands addon for Visual Studio '08. You can right click the solution in the Solution Explorer and choose "Remove And Sort" usings. Also, there are options in the Tools-->Options dialog box (scroll down to the Power Commands item) for removing on save and reformatting your code ( using vs settings ) on save.