- VB: Report a warning about AssemblyKeyFile and AssemblyKeyName attributes being ignored by public signing.
- Disallow public signing for Net modules. The fact that the signing is public is not preserved in a module. The fact of signing is preserved by emitting attributes that are going to be ignored anyway if public signing is used.

Closes #11427.

Fixes #15910
Also fixes a sequence point issue with the let expression. Specifically, the source range for the query lambda included more than the expression of the let, but included the entire query clause. It now includes only the expression, like other query clauses.

Related to dotnet/coreclr#7914
Where the offending pattern was observed in the IL generated for the Kestrel web server and was recommended as an easy improvement.

Becasue of cascaded dispatching into "try" regions , it is not uncommon to see async state machine to contain degenerate switches like

IL_0008:  switch     (
                          IL_003b,
                          IL_003b,
                          IL_003b,
                          IL_003b,
                          IL_003b,
                          IL_003b,
                          IL_003b,
                          IL_0729)

Note numerous cases all leading to the same target.
We can trivially emit such switches as just a range-check (that switch would need to do anyways), without any actual "switching".
Since all cases lead to the same label anyways, there is no need to switch once we know the value is in range of the switch.

Fixes:#14878

Similar change as to TestUtilities.  Insteading of having two
independent projects with shared sources there are now a portable and
desktop only version.  The desktop version references the portable one.

Code move before refactoring it.

The Compilers.sln solution is compiling again and tests which don't
require AppDomain support are running again.  There is a bit of work
that is needed for AppDomains that I want to separate out.  In
particular the separation to portable means we have to redo some of the
serialization code.

Fixes https://devdiv.visualstudio.com/DevDiv/_workitems?id=296550.

Add test for specified behavior of a virtual method invocation (via a binary compatibility scenario). (#16055)

* Add test for specified behavior of a virtual method invocation (via a binary compatibility scenario).

This property is controlled by our central build targets.  It shouldn't be used in indivdidual projects anymore as it can lead to bugs.  See the following PR from @KirillOsenkov for an example of how this leads to bugs

https://github.com/dotnet/roslyn/pull/15880

Fixes #15734

Fixes #15934

This fixes a MSB3568 warning during the build of CrossPlatform.sln on
Linux.

See #15751

Fixes https://devdiv.visualstudio.com/DevDiv/_workitems?id=217718.

There were two root causes here:

    1) The rewriter was treating the difference between the symbol and
       `symbol.ConstructedFrom` as whether or not there were any type
       parameters remaining that may need substitution. This is invalid
       for recursive local functions.

    2) The local function reference rewriter was including type
       parameters from the containing type in the list of parameters to
       substitute. This should happen iff the containing type is a
       lambda frame used to capture variables, which is not always the
       case for local functions (although it is always the case for
       lambdas).

Fixes #15751

There were two versions of the CreateMonitorDisconnect task: client and
server.  This code is the same and having it in two places was making it
difficult to track down a customer investigation.  Merging into a single
location.

It's used in the logging scenarios.

This change will cause our bootstrap build to fail if a threshold of server connection failures
occur.  The threshold is chosen a bit arbitrarily as valid failures can occur.  But 15 seems like
a number to warrant an investigation.  If this produces too many false positives it will be
adjusted appropriately.

Local functions have already implemented their own frame management,
including frame pointer "capturing" (which is implemented by passing a
list of frames to the local function by-ref, rather than traditional
lambda capturing which is implemented by keeping a linked list of frame
pointers to parent frames).

PR #14736 wired up local function lowering to the lambda frame pointer
machinery, which is necessary for when a local function is captured by a
lambda or converted to a delegate, but in the process it diverted
control flow for pure local function capturing to the frame pointer
machinery, which can't handle the structure of local function struct
frame pointers.

This PR resolves the issue by restoring the control flow for local
functions capturing other local functions with by-ref struct frames.

Fixes #15599