{"action":"created","issue":{"url":"https://api.github.com/repos/dotnet/sdk/issues/436","repository_url":"https://api.github.com/repos/dotnet/sdk","labels_url":"https://api.github.com/repos/dotnet/sdk/issues/436/labels{/name}","comments_url":"https://api.github.com/repos/dotnet/sdk/issues/436/comments","events_url":"https://api.github.com/repos/dotnet/sdk/issues/436/events","html_url":"https://github.com/dotnet/sdk/issues/436","id":192171890,"number":436,"title":"Use simple names for SDK specifiers","user":{"login":"dsplaisted","id":145043,"avatar_url":"https://avatars.githubusercontent.com/u/145043?v=3","gravatar_id":"","url":"https://api.github.com/users/dsplaisted","html_url":"https://github.com/dsplaisted","followers_url":"https://api.github.com/users/dsplaisted/followers","following_url":"https://api.github.com/users/dsplaisted/following{/other_user}","gists_url":"https://api.github.com/users/dsplaisted/gists{/gist_id}","starred_url":"https://api.github.com/users/dsplaisted/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dsplaisted/subscriptions","organizations_url":"https://api.github.com/users/dsplaisted/orgs","repos_url":"https://api.github.com/users/dsplaisted/repos","events_url":"https://api.github.com/users/dsplaisted/events{/privacy}","received_events_url":"https://api.github.com/users/dsplaisted/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2016-11-29T02:29:30Z","updated_at":"2016-11-29T17:47:54Z","closed_at":null,"body":"Related to #415 and Microsoft/MSBuild#1392\r\n\r\nIn 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:\r\n\r\n**.NET SDK**\r\n```xml\r\n<Project Sdk=\".NET\">\r\n  ...\r\n</Project>\r\n```\r\n\r\n**Web SDK**\r\n```xml\r\n<Project Sdk=\"ASP.NET\">\r\n  ...\r\n</Project>\r\n```\r\n\r\nFor 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.\r\n\r\nWhen 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`.\r\n\r\n@srivatsn @AndyGerlicher @piotrpMSFT @yishaigalatzer"},"comment":{"url":"https://api.github.com/repos/dotnet/sdk/issues/comments/263644227","html_url":"https://github.com/dotnet/sdk/issues/436#issuecomment-263644227","issue_url":"https://api.github.com/repos/dotnet/sdk/issues/436","id":263644227,"user":{"login":"cdmihai","id":2255729,"avatar_url":"https://avatars.githubusercontent.com/u/2255729?v=3","gravatar_id":"","url":"https://api.github.com/users/cdmihai","html_url":"https://github.com/cdmihai","followers_url":"https://api.github.com/users/cdmihai/followers","following_url":"https://api.github.com/users/cdmihai/following{/other_user}","gists_url":"https://api.github.com/users/cdmihai/gists{/gist_id}","starred_url":"https://api.github.com/users/cdmihai/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cdmihai/subscriptions","organizations_url":"https://api.github.com/users/cdmihai/orgs","repos_url":"https://api.github.com/users/cdmihai/repos","events_url":"https://api.github.com/users/cdmihai/events{/privacy}","received_events_url":"https://api.github.com/users/cdmihai/received_events","type":"User","site_admin":false},"created_at":"2016-11-29T17:47:54Z","updated_at":"2016-11-29T17:47:54Z","body":"> I also think that \"SDK\" is just another word for \"development dependency\" or most recently \"build time\" \r\n\r\nI'd be in favor for separating the population of packages into 2:\r\n- build augmentor packages: packages that extend the meaning of what it means to build a project. At the low level you'd have core SDKs, that bring in the language and general flavor of the project. These are the things that ship with the CLI / VS (e.g. a UWP, F#, .net core application :) ). At the higher level you have cute tools that print your dependency graph, test executors, linters, fancy cloud deployment things, etc\r\nMSBuild understands the layout and contents of these packages, and knows how to integrate a build augmentor's assets (props, targets, tasks) in the build.\r\n- runtime packages: packages that provide extra code (usually binary) that the runtime application that is being built depends on. MSbuild does not understand the contents of these packages. The application runtime (CLR, CoreCLR, Mono) knows how to find and load these dependencies. The low level build augmentors know how to unpack them such that the runtime for the specific project flavor (Full Framework dependency resolution / layout vs .net core dependency resolution / layout) can find and load them. Runtime packages usually consist of binary code packaged in that language's de facto binary package format (dlls, jars, etc)\r\n\r\nThe separation between these two package types could be made via the new [package type qualifier](https://docs.nuget.org/ndocs/create-packages/creating-a-package#setting-a-package-type) that nuget now supports. And the types are exclusive: a package either augments the build, either adds a runtime dependency.\r\n\r\nThis means that current packages that both augment the build and bring in runtime dependencies will have to be split up. Junit for example, which both provide a runtime package (test specific types and utilities) and a build augmentor package (that drops in a test executor wrapped task, targets, VS test discoverer, etc). This kinda makes sense, since there could be third party providers that want to provide their own, fancier test executors but reuse the Junit types.\r\n\r\nBackwards compatibility wise, it's going to be interesting on what to do with the current population of hybrid population: suddenly break them, have nuget issue errors (tool and / or hosting sites), etc"}}
{"actor":{"display_login":"cdmihai"}}