Develop Reference

How to hide the ... that appeared everywhere in Visual Studio 16.10?

How to hide the ... that appeared everywhere in Visual Studio 16.10?
e.g.
It appears for unused usings, expression value not assigned, and many more.
[I'm NOT asking how to turn off graying out of unused usings.]

Dots like that, along with squiggly underlines, are coming from diagnostics issued by the compiler and analyzers.
Each diagnostic has its own identifier code such as CS1234 or IDE1234, etc.
You can configure the severity of each of these as described here:
https://learn.microsoft.com/en-us/visualstudio/code-quality/use-roslyn-analyzers?view=vs-2019
The easiest way is to add/edit your .editorconfig file and put the following in:
dotnet_diagnostic.<rule ID>.severity = <severity>
Where <rule ID> is the diagnostic ID, and <severity> is one of none, silent, suggestion, warning or error.
This gives you very fine grained control over these kinds of tips in your solution.
If you put the .editorconfig file in the root of your repo, it will apply to all projects in the solution.
Here's an example of using the lightbulb menu (Ctrl+.) to configure the severity of a diagnostic with code VSTHRD002:
There's also a section "Suppress ..." which lets you suppress a specific instance of the diagnostic, in contrast to changing the severity which applies across a broader scope.
Note you have have multiple .editorconfig files. For example, if all your unit tests are under a test folder, you could drop an .editorconfig file in there that has more relaxed rules.

Go to source in a multi solution enviroment in Visual Studio 2019

We have a scenario like this:
We have ~100 solutions containing 10 projects each.
Each solution copies its artefacts (i.e. its 10 dlls) to a shared single folder like C:\code/assemblies.
If I develop something for feature X, I'll open up SolutionX.
The source for all solutions/projects is local in a single Monorepo C:\code.
During debugging, when the method/class/whatever is implemented in project Y, it opens the corresponding file (which is nice). So there must be information available how to get to the source.
But when developing, I cannot navigate to the implementation e.g. by using F12 ("go to definition") but just get the signatures gathered from meta data. I'd like to have the same experience like during debugging.
So right now I open up a Visual Studio Code, open the folder containing the sources and do a "search in files".
Any better ideas?
N.b. Resharper is not an allowed option. Also doesn't play nice with Postsharp.
N.b. I don't know if it is important but all except one solution start an external program (the shell), since all except one solution contain only dlls.

I have done similar in Old project.
You can use Symbol with Visual Studio 2019. Simple steps can be:
A. Generate Symbols for projects :
In Solution Explorer, select the project.
Select the Properties icon (or press Alt+Enter).
In the side pane, choose Build.
In the Configuration list, choose Debug or Release.
Select the Advanced button.
In the Debugging information list, choose Full, Pdb-only, or Portable.
Refer for more information:
Set debug and release configurations in Visual Studio
Publish symbols for debugging
B. Use Symbol in Visual Studio:
In Visual Studio, open Tools > Options > Debugging > Symbols (or Debug > Options > Symbols).
Under Symbol file (.pdb) locations,
To use the Microsoft Symbol Servers or NuGet.org Symbol Server, select the checkbox.
To add a new symbol server location,
Select the + symbol in the toolbar.
Type the URL (http), network share, or local path of the symbol server or symbol location in the text field. Statement completion helps you find the correct format.
Tools - Options - Debugging - Symbols page
For more Details refer:
Configure symbol locations and loading options

I think you should analyze project dependencies (for example with https://www.ndepend.com/docs/visual-studio-dependency-graph ) and cluster your projects in less Solutions

Edit : I am editing this answer based on your comment. I think you are looking for two use cases
Peek into the source code of referenced binaries
Navigate to the source and then edit them in place
To achieve option (1)
In Visual Studio 2019, use the built in decompiler to help you with navigating to code outside of the solution. This is an experimental feature as of May 2020. By default this is disabled and you should enable it. Once enabled the F12 navigation will decompile and allow you to peek into the source code.
On the other side, the more you relax the compilation the better the decompilation. Meaning, you can turn off optimisations (if any). This doesn't have to do anything with symbol generation options.
If you are using visual studio 2017 (or) less, the same can be achieved by Telerik Just Decompile plugin (free). Check the feature View decompiled code in tabs
To Achieve option (2) :
You should reference source files rather than binaries, because you won't get the natural in-place edit with referencing binaries. There are always going to be caveats irrespective of the solution you choose. Referencing source can be done using the "Add as link" feature in Visual studio, where the source code belong to one solution and can be referenced as link (something like windows shortcuts) in all the other solutions. (https://andrewlock.net/including-linked-files-from-outside-the-project-directory-in-asp-net-core/). If you are referencing source, you need to remove the binary references.
And you also have to decide from an architectural standpoint on how this changes the way people develop and commit code. The point of referencing binaries is to make sure they are not edited for convenience, but that depends on the nature of the development team purely.
Conclusion
From a best practices standpoint, you either have to reference binaries and don't allow them to be edited (or) you allow source references and edit in place. But that depends purely on what you want to achieve.

Disable "Name can be simplified" IDE0003 fix hint

Visual Studio 2017 shows a hint for unnecessary this qualifiers even when the inspection is disabled in the options.
This is how it looks:
(First line is the culprit, second line is how I want this to always look like.)
Hovering over the grayed out this and clicking on the light bulb shows this suggested fix:
I can't find a way of disabling this completely. Sometimes I want to have "unnecessary" this qualifiers and sometimes I don't, so I don't want VS to comment about this at all.
"None" is the least severe option yet it still shows this annoying, different color.
Is there any possibility of complete disabling this inspection?

You can use a ruleset file to disable any analysis if you know its diagnostic id (in this case 'IDE0003')
On the References node of you project right click on Analyzers and select Open Active Rule Set
Once the ruleset editor is open just search for IDE0003 and uncheck the checkbox. Then save the ruleset file. Then save the project.
The following XML will be added to you project file. You can add this ruleset file to any project where you want this rule disabled.
<CodeAnalysisRuleSet>ConsoleApp9.ruleset</CodeAnalysisRuleSet>

Looks like the current process is more complicated for .NET Core and .NET Standard projects.
From MS VS Docs:
If you have a .NET Core or .NET Standard project, the process is a little different because there's no Code Analysis property tab. Follow the steps to copy a predefined rule set to your project and set it as the active rule set. After you've copied over a rule set, you can edit it in the Visual Studio rule set editor by opening it from Solution Explorer. [emphasis mine]
Taking the first link in that quote will eventually take you, after a little sleuthing, to Code style rule options, that finally tells you how to add the file:
In Visual Studio, you can generate this file and save it to a project at Tools > Options > Text Editor > [C# or Basic] > Code Style > General. Then, click the Generate .editorconfig file from settings button.
NOTE: This produces a tiny warning just under your toolbars that an .editorconfig has been added to your solution. Select the "Yes" button to include it in your solution.
And now you can open and edit your new .editorconfig file.
Looks like this is the "offending" section:
# this. and Me. preferences
dotnet_style_qualification_for_event = false:suggestion
dotnet_style_qualification_for_field = false:silent
dotnet_style_qualification_for_method = true:suggestion
dotnet_style_qualification_for_property = false:suggestion
If that dotnet_style_qualification_for_property is changed to = true:suggestion (explanation here), I think you're golden [at least for properties, of course -- make edits as appropriate].

Hierarchy of code analysis rulesets?

I've got a solution containing two MVC 5 web applications with associated class libraries and the code analysis settings are causing the build to hang. If I try to interact with the UI during this time I get the "VS is busy" bubble. Leaving the build to complete overnight doesn't work either.
To troubleshoot this I turned off code analysis on all projects and the project builds just fine [0]. So I enabled the "Microsoft All Rules" on one of the MVC projects and the build process doesn't complete.
"Microsoft Managed Minimum Rules" builds but what I'd now like is that there's some kind of structured way of going through the rulesets, where the next one I try is a superset of the last successful one. Does such a hierarchy exist, and if so, is there a canonical reference for it?
Once I get to that level then I can start to isolate individual rules, perhaps by increasing the verbosity of the build output...
[0]
This statement should not be interpreted as "Building without code analysis is perfectly okay"

A general hierarchy is exposed via the Include elements in the .ruleset files located under the Visual Studio install directory (e.g.: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\Rule Sets for a typical VS 2015 installation). Broadly, it looks something like this (with "All Rules" not actually depending on any of the others):
All Rules
Extended Correctness Rules
Basic Correctness Rules
Minimum Recommended Rules
Extended Design Guideline Rules
Basic Design Guideline Rules
Minimum Recommended Rules (same as above)
Globalization Rules
Security Rules
It's also worth noting that this isn't a clean hierarchy without overlaps. For example, rules included in the "Globalization" and "Security" rulesets are also included in some of the others (including the "Minimum" set).

To inherit from a ruleset file, you can include it with:
<Include Path="MyOther.ruleset" Action="Default" />
Then you can override the action for specific rules.

Inetgrating custom Fxcop rule with existing Fxcop rule

I have developed some Fxcop custom rule and I want to create seperate project just like 'Design Rules','Globalization Rules' etc which will contain custom rule which was designed by me and some selected existing Miscrosoft Fxcop Rules. I want to know whether it is possible to do so. If possible ,How ?

You would have to place the custom rule dll-file in your correct FxCop-rulelocation:
This can be C:\Program Files (x86)\Microsoft Visual Studio 11.0\Team Tools\Static Analysis Tools\FxCop\Rules for example. Find your location and place it in there.
What you want to do next is create a Code Analysis Ruleset.
There is a Microsoft tutorial on creating Code Analysis Rulesets here.
To open an empty rule set file in the rule set editor
On the File menu of Visual Studio, point to New and then click File.
In the New File dialog box, click General in the Installed Templates list, and then select Code Analysis Rule Set.
The rule set editor appears. No rules are selected in the editor list.
What you see next is the Rule Set Editor. Here you can select existing rules and also your own, custommade rules.
Working with the ruleset editor is explained here.

There is a step-by-step guide available at http://blogs.msdn.com/b/codeanalysis/archive/2010/03/26/how-to-write-custom-static-code-analysis-rules-and-integrate-them-into-visual-studio-2010.aspx for authoring rules and adding them to .ruleset files. To figure out where the problem is originating, it would be best to follow all the recommended steps, including verifying that the rule can be executed by the fxcopcmd.exe command line tool.