Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Use simple names for SDK specifiers

See original GitHub issue

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:


<Project Sdk=".NET">


<Project Sdk="ASP.NET">

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

Issue Analytics

  • State:open
  • Created 7 years ago
  • Comments:11 (10 by maintainers)

github_iconTop GitHub Comments

davidfowlcommented, Dec 8, 2016

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.

cdmihaicommented, Dec 8, 2016

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/, 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/`
`web` => `Microsoft.Asp.Net/`
`Android` =>`Foo.Mobile.Android/`
`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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Implicit top & bottom SDK imports #1392 - dotnet/msbuild
SDK imports represent the extension mechanism for MSBuild's build framework model: a ... Use simple names for SDK specifiers dotnet/sdk#436.
Read more >
What is a nested name specifier? - c++
In informal terms 1, a nested-name-specifier is the part of the id that ... Notice that I used ::count where I could have...
Read more >
Naming Files, Paths, and Namespaces - Win32 apps
The Win32 namespace prefixing and conventions are summarized in this section and the following section, with descriptions of how they are used.
Read more >
How to remove Cloud Firestore field type specifiers when ...
Is it possible to remove those when making a GET call? In short No. The Firestore REST API GET returns an instance of...
Read more >
API: Getting Data and Methods of Access
To form a specifier for a simple single-value attribute, use table name + element code. For complex attributes use table name + the...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found