Version Bump (dotnet#2334)

To unblock our internal build.

Implicit facades for netstandard 1.x references (dotnet#2304)

Add target framework metadata to TargetPathWithTargetPlatformMoniker and check it in ImplicitlyExpandDesignTimeFacades

Fixes dotnet/sdk#1393

Perf improvements (dotnet#2246)

* Cache search paths directory checks in the Evaluator

* Add more lazy Traits
- fixes dotnet#2247

Revert RAR AssemblyInformation caching (dotnet#2215)

In .NET Core, it's safe to use an AssemblyInformation object without
disposing it, but that's not true in full framework because of the use
of COM objects to extract information from the assembly. Backing out the
cache until we can test a fix that correctly disposes the objects
(including for RAR failures and exceptions).

This reverts commit be56bc3.

This reverts commit 55f846e.

vbump to work around build issues

Fix build XamlBuildTask failure on 64-bit MSBuild (dotnet#2001) (dotn…

…et#2020) (dotnet#2059)

Allows 64-bit MSBuild to find XamlBuildTask.dll to build 64-bit Xaml projects.

Related to internal issue DevDiv.372915.

Fix issue importing an SDK via Import element. (dotnet#2038)

* This feature was regressed in dotnet#2002
* Update unit tests to verify functionality
* Update ProjectParser to parse SDK name/version values and construct an SdkReference object to be used by the evaluator.

Closes dotnet#2034

Merge pull request dotnet#1766 from rainersigwald/item-case-sensitivi…

…ty-1751

Item references should be case-insensitive

Work around dotnet#1675 for C++ Code Analysis scenarios (dotnet#1699)

This addresses the repro case for dotnet#1675, but not its root cause. By
providing a `codeBase` for the CA assemblies, we ensure that any running
MSBuild can find them when deserializing a log message.

Respect projects that say they only have one TFM (dotnet#1667)

Partially fixes dotnet/sdk#739.

The first iteration of cross-targeting support code unconditionally
queried each ProjectReference for the best TFM to build against, and
then explicitly specified that TFM when building the reference. This
caused a race condition when building a set of projects that had a
single-TFM project and another project that had a reference to it. The
entry point (probably .sln) build would build the referenced project
with no TF specified, and then the referencing project would build it
with an explicit TF specified. These two builds appeared different to
the MSBuild engine (because they had different sets of global
properties) and so were both executed, resulting in a race condition.

The fix is in two parts:
* Allow a project to report back through GetTargetFrameworkProperties
that it only has one TF to build.
* When a project reports that it has only one TF to build, issue its
build request without specifying any TF.

This commit is the latter.