This reverts commit d43d4780.

This reverts commit d43d4780.

This reverts commit 7bb0b4ea.

This reverts commit d43d4780.

Avoid rebinding references bound to explicitly specified definitions, even if a better version is available after resolution

These were accidentally changed to UTF-16LE during a recent scripted change.  This went unnoticed because the encoding change didn't register in CodeFlow (indeed if you view a shelve of this change in CodeFlow it will report no changes).  UTF-16 does not work well with Git as it is often interpreted as a binary file.  Moving back to UTF-8 so our GitHub experience works well for customers.

closes #66 (changeset 1403787)

Background:

As discussed in the dev team all hands all code under the GitHub dotnet foundation is using a single process for contribution, API review, infrastructure and coding style. The idea is to present a unified view to our customer and give them a single story for contributing to any project under the dotnet foundation.

https://github.com/dotnet/corefx/wiki/Contributing#c-coding-style

The coding style transition is automated using a Roslyn based rewrite tool:

https://github.com/dotnet/codeformatter

This will be applied in stages across our developer tree. Right now the focus is on the Open directory as this is what is being presented on github. Code owners will be contacted before the transition happens.

Note: this is a soft style requirement. There are no build errors that come from this change.
 (changeset 1403394)

In some parts of our codebase, we use "verbatim crefs" where the compiler just passes the cref name out to the XML file and doesn't do any analysis of it. While there are some legitimate uses of these, there were many abuses in our source code. Worst of all, in some cases we had verbatim crefs on public types that referenced types that had since been renamed, or the syntax was wrong, etc. With this change, there's now an analyzer that issues a warning for all uses of them. In the places that are fair uses of them, the warning is suppressed. Going forward, adding suppressions should be considered fine as long as:

1) it's a reference to something in another layer or language
2) it's some framework type that's clearly never going to change ever

Otherwise, a proper, verifiable syntax should be used. Again, this isn't to say that verbatim crefs are universally bad, but just that we've proven we make mistakes with them and some guards should be put in place. (changeset 1360175)

Splits Microsoft.CodeAnalysis, Microsoft.CodeAnalysis.CSharp and Microsoft.CodeAnalysis.VisualBasic into portable and desktop assemblies.

Existing Core\Source, CSharp\Source and VisualBasic\Source directories are renamed to Core\Portable, CSharp\Portable and VisualBasic\Portable.
New sibling Desktop folders are added and non-portable source is moved there.
"System.Runtime" references has to be removed in order for the portable project system magic to automatically add facade references.
 (changeset 1281686)

We stored a CorLib assembly symbol (one that doesn't have any references and defines System.Object) on ReferenceManager. The instance of the manager is shared across compilations derived via Clone() or WithXxx() unless the metadata reference binding changes.
     If the compilation itself was CorLib we shared its source assembly symbol as a CorLib assembly with the derived compilations, which broke symbol equality.

     This change replaces an explicit CorLib reference in the ReferenceManager with null if the CorLib is the compilation being compiled. We have the assembly CorLib symbol in hand when reading the state so we can fill the right symbol in.
     Also refactors VB code in ReferenceManager to exactly match C# implementation.

     Resolves #43. (changeset 1227802)

The goal of this change is to allow specification of multiple aliases for a metadata reference and thus simplify code in services and also allow for moving non-portable part of metadata reference property merging out of the compiler.
     As a byproduct this change fixes 2 bugs in the compiler:
     1) Given two copies of a signed strongly named assembly foo.dll copied in two directories A and B one could trick the compiler to accept an incorrect input for which an error should be reported:
         csc /reference:A\foo.dll /link:B\foo.dll

         Currently this just ignored one of the argument (the first one) and embedded interop types. We already reported an error if the references were merged due to paths being the same, but when the identities were the same we just ignored the reference.
         This change reports an error.
     2) <externinfo> custom debug info was only emitted for the first of the extern aliases associated with a metadata reference. We should emit the info for all aliases. I have filed bug 913022 to track a related issue with usings.

     Details:
     Currently MetadataReferenceProperties only allow to specify at most one alias for the reference. User can however possible to specify more than one alias both on the command line and in VS.

     On command line this is done by repeating the /r argument with the same (normalized) path. A couple of examples:
     1)  csc /r:A=foo.dll csc /r:B=foo.dll
           Symbols from foo.dll can be referred to via extern aliases A or B.
     2)  csc /r:A=foo.dll csc /r:foo.dll
           Symbols from foo.dll can be referred to via an extern alias A or without an extern alias.
     3)  csc /r:A=A\..\foo.dll csc /r:B=FOO.DLL
           Symbols from foo.dll can be referred to via extern aliases A or B. The normalized paths are equal.

     In VS the Properties window for a reference has "Aliases" entry where one can type comma separated list of aliases, e.g. "A,B" which corresponds to case 1) above, or "A,global" meaning the same as 2)
     msbuild actually converts these values to multiple references on command line.

     Roslyn VS language service currently needs to create and keep track of instances of MetadataReference for each specified alias, which is complicating already complex code dealing with project and metadata references.

     The ReferenceManager in the compiler compares normalized paths of metadata references in order to find out that it should merge two metadata references. This change keeps that behavior for now, but enables us to move this logic outside of the compiler to csc.exe/vbc.exe. I'll follow up with that change.
 (changeset 1216193)