Use simple names for SDK specifiers

Related to #415 and Microsoft/MSBuild#1392

In the interest of having clean project files, we should consider making the names used to specify which SDK is used as simple as possible. I’d suggest the following:

.NET SDK

<Project Sdk=".NET">
  ...
</Project>

Web SDK

<Project Sdk="ASP.NET">
  ...
</Project>

For the next preview, this is simply a matter of updating the templates and laying out the files in the MSBuildSDKsPath under the appropriate folder names.

When we have an acquisition story for SDKs, it will probably involve downloading them as NuGet packages. We wouldn’t want to publish our Sdks as NuGet packages with the names .NET and ASP.NET. One way to solve this would be to automatically prepend something like MSBuildSDK to the name specified in the Sdk attribute (and to add a period if the Sdk attribute value didn’t start with one). Thus, the NuGet package names would be MSBuildSDK.NET and MSBuildSDK.ASP.NET. We could also consider replacing a # with Sharp so that, for example, Sdk="F#" would map to an Sdk NuGet package with an ID of MSBuildSDK.FSharp.

@srivatsn @AndyGerlicher @piotrpMSFT @yishaigalatzer

[davidfowl]

Build time dependencies SDKs or tools can use same nuget mechanism, but use a separate myget-like repository maintained by MSBuild.

Where tools are doesn’t matter. What matters is how they manifest themselves in the project file and what the system that pulls them down does. I think using nuget would be fine if we had a way to:

• Use pre-installed nuget packages
• Restore a separate graph per logical exe (one for msbuild, one per tool, one for csc loading analyzers)

All build time dependencies should be installed globally.

Nah, it should be possible to acquire it without installing it globally.

Dotnet cli tools can merge with MSBuild tools in future, given similar API support in MSBuild.

That doesn’t make any sense. Tools are separate from msbuild targets/tasks/sdks. SDK is not an exe launcher.

[cdmihai]

All build time dependencies should be installed globally.

Nah, it should be possible to acquire it without installing it globally.

It would be nice to have a “per workspace” way of setting up things (an msbuild workspace would be similar to a VS solution, but none of the solution crud). When users have workspaces with more than a few projects, it would be nice to set versions in one place rather than doing a recursive search and replace and hope that unification works right.

Doubling back to the original issue, maybe shorthand SDK aliases would work well with such a “per workspace” build config file. The workspace build config file defines the alias (core => Microsoft.Net.Core/1.2.3.4), and the projects use the aliases. Maybe the build config file could also alias groups of SDKs under a single name, like:

`core` => `Microsoft.Net.Core/1.2.3.4`
`web` => `Microsoft.Asp.Net/2.3.4.5`
`Android` =>`Foo.Mobile.Android/3.4.5.6`
`MyProjectFlavor` => `core;web;Android`

Then, the actual projects could use <Project SDK="MyProjectFlavor">

Simple, single toy projects could use some Microsoft hardcoded aliases which have the lowest priority when alias names are resolved.