When a compilation fails the compiler should not delete or edit the outputs of a previous successful.  They should remain around to satisfy scenarios like F5 on build failure.

Roslyn implemented this logic by doing the following:

- Creating a `Stream` for the assembly / PDB in a temp directory.
- Running the compilation.
- Moving the `Stream` to the desired output location on success.

This introduced a subtle bug into the compiler.  When the source + dest of `File.Move` are on the same volume the destination file will end up with the ACLs it got from being created in the source directory.  In this example it meant the assembly / PDB had the ACLs of the temp directory not the actual output one.

This can produce breaks in cases where the temp and output directory have different inheritable ACLS.  This case comes up for instance in ASP.Net.

To fix this we are going back to the native compiler behavior here.  The creation of the `Stream` objects will be delayed until we are ready to write to disk (happens after the compilation is verified to have no errors).

Because this portion of the compiler is on .NET 4.5.2 the Emit layer cannot open the files directly (no file system API to use).  Instead we pass down the `EmitStreamProvider` abstraction from the desktop layer and let that control the openning of the files.

This change also allows us to remove all of the temp directory logic from the compiler and build protocol.

Note: Whether or not to make this entry point a public API is being considered separately from this thread.  If we decide to make this public it will be done as a separate follow up change.

This reverts commit b37052d0.

This reverts commit 90215346.

Use empty array for unspecified public key instead of default(ImmutableArray<byte>) to avoid issues with JSON serialization

And seal its base type DiagnosticDescriptor.

(Fixes #789)

Enable hosts to compile strong-named assemblies on all platforms by supplying public key via compilation options and also enable OSS signing with such key

This change set introduces the notions of registering compilation actions and code block actions into the diagnostics API. Compilation actions differ from compilation end actions in that they do not have access to per-compilation analyzer state and do not introduce action execution ordering constraints. Code block actions differ from code block end actions in that they do not have access to per-block analyzer state and do not introduce action execution ordering constraints.

This change set also removes RegisterXEndAction methods on contexts other than the corresponding StartXAnalysisContext types. This change is intended to guide analyzer authors towards introducing analyzer state with appropriate lifetime.

Some internal mechanism for the removed registration methods remains. This keeps the mechanism fully general and imposes a very marginal execution cost.

The specific API changes:
 -- Removal of AnalysisContext.RegisterCompilationEndAction. CompilationStartAnalysisContext.RegisterCompilationEndAction remains.
 -- Removal of AnalysisContext.RegisterCodeBlockEndAction and CompilationStartAnalysisContext.RegisterCodeBlockEndAction. CodeBlockStartAnalysisContext.RegisterCodeBlockEndAction remains.
 -- Introduction of AnalysisContext.RegisterCompilationAction.
 -- Introduction of AnalysisContext.RegisterCodeBlockAction and CompilationStartAnalysisContext.RegisterCodeBlockAction.
 -- Renaming of CompilationEndAnalysisContext to CompilationAnalysisContext.
 -- Renaming of CodeBlockEndAnalysisContext to CodeBlockAnalysisContext.

Fixes #950: Seal public methods of DiagnosticAnalyzer that can be overridden and can throw: Equals,GetHashCode and ToString. This is required as we use analyzers as keys for various caches in our diagnostic engines.

Also fix an issue pointed out by CyrusN: Don't report analyzer diagnostics for OperationCancelledException during analyzer execution.

Address CR feedback from Heejae: Avoid unnecessary IEqualityComparer<AnalyzerAndOptions>, set concurrency level for concurrent dictionary, and add early out checks based on reference equality in added Equals overrides.

Looks like some of the MSBuild files got checked in under Src instead of
src.  This corrects that.

closes #1045

Fix execution of CompilationStartActions when only analyzer options for the project change, but the underlying compilation is identical.

Our current assumption for executing CompilationStartActions is that they should be executed exactly once per-compilation per-analyzer. We cache the registered nested actions for every compilation in AnalyzerManager to ensure this. However, if user just changes an additional document for the project, then the analyzer options change, but the underlying compilation is unchanged. Project change causes IDE diagnostic service to clear all cached diagnostics, but when re-computing diagnostics, we end up skipping execution of CompilationStartActions and directly move to nested compilation actions. This can be troublesome in couple of ways. First, we will have duplicate callbacks for all nested actions for the initially invoked compilation start action. Second, and event worse, if the analyzer is reading the contents of the additional documents in the start action and caching them for later use by the nested actions, all the nested actions get stale contents for the additional documents. Apparently, Tom is the first one to go through this agony as the DeclarePublicAPI analyzer that he implemented exactly does the latter.

Fix is to ensure that we execute compilation start actions for every unique compilation start analysis context, i.e. {compilation, analyzer options} tuple for every analyzer.

SymbolEquivalenceComparer improvements: custom assembly comparer, handling custom modifiers, comparing method return types

Brings back the managed client and reworks the two new build
task specific tests to compile using the managed client inside
the build task.

Address feedback from Tom: Ensure that we unsubscribe the exception handler registered with LocalizableString when the analyzer reference is disposed by the host. This will prevent statically instantiated LocalizableString instances from leaking the handler, and hence the analyzer instance.
We now have a public OnException event on the LocalizableString, which is invoked on exceptions. AnalyzerManager registers host's exception handler when populating descriptor cache per analyzer and unregisters this handler when host is disposing the analyzer.

Revert "Address review feedback from Heejae: add DiagnosticDescriptor.WithOnException to create a new descriptor with hooked up exception handler for reporting exception diagnostics from LocalizableStrings, instead of mutating fields of LocalizableString implementations."

This reverts commit 4e120580.

Address review feedback from Heejae: add DiagnosticDescriptor.WithOnException to create a new descriptor with hooked up exception handler for reporting exception diagnostics from LocalizableStrings, instead of mutating fields of LocalizableString implementations.

This is the final change in the series of changes I have been making to ensure that compiler and IDE are completely hardened against exceptions from analyzers.

This change makes the DiagnosticDescriptor completely exception safe. Currently, DiagnosticDescriptor has lazily evaluated LocalizableString fields for Title, MessageFormat and Description. These have public extension points at ToString, Equals and GetHashCode methods, all of which can throw. These callbacks have now been wrapped within a try-catch for our LocalizableResourceString implementation of LocalizableString. For custom user implementations of LocalizableString (which should hopefully be rare), we wrap these within an ExceptionSafeLocalizableString which calls into the inner localizable string wrapped within a try-catch. All this is done within the DiagnosticDescriptor constructor, none of the clients have to explicitly handle the exception at use sites.

This change brings back the SimpleMSBuild test, which sets
up a "hello world" C#+VB solution and builds it using msbuild using
the build task.

Two build-task-specific tests have also been added, which directly
load and call execute on the Csc and Vbc tasks.

Closes #866.

Replace many uses of uint which are unwrapped string indices with
StringIdx, the wrapped form, for type safety.

Been almost a month since the code formatter was run so this change was
a bit larger than would be expected for a normal (weekly) update.  Diffs
mostly around:

- Whitespace changes
- Missing copyright headers
- Missing visibility modifiers

Add a comment explaining why
`AnalyzerFileReference.InMemoryAssemblyLoader.CurrentDomain_AssemblyResolve`
catches all exceptions.

These files are a hold over from when Roslyn was in TFS.  They aren't
needed anymore now that we are in git.

closes #858

Leaking an exception from an `AppDomain.AssemblyResolve` event handler
may interrupt the entire assembly resolution process, which is
undesirable. Instead, we should just return null and give other handlers
and/or the CLR a chance at assembly resolution.