Create new package type for MSBuild project SDKs

[jeffkl]

In MSBuild 15.6 (dotnet/msbuild#2803), we shipped a NuGet-based project SDK resolver that allows users to specify something like this:

<Project Sdk="MyCustomSdk/1.0.0">
</Project>

The SDK resolver in MSBuild queries the configured NuGet feeds for a package with the same ID and version and then returns the path to it on disk. These kinds of packages could have special considerations.

SDK packages must have a root Sdk folder and contain two MSBuild project imports named Sdk.props and Sdk.targets.

Example:

foo\1.0.0
└───Sdk
        Sdk.props
        Sdk.targets

However, there's nothing technically wrong with a package containing reference assemblies, runtime assemblies, build logic, and an SDK.

foo\1.0.0
├───build
│       foo.props
│       foo.targets
│
├───lib
│   └───net46
│           foo.dll
│
├───ref
│   └───net46
│           foo.dll
│
└───Sdk
        Sdk.props
        Sdk.targets

We also need to nail down what it means for an SDK package to have a dependency on another package. At the moment, dependencies are ignored but there could be a use case for this to work where the import order is just the same as dependency order.

[nkolev92]

I have a couple of questions I'd like us to clarify before continuing here. I will schedule an offline meeting to discuss this.

For example, what's the point of build/foo.props etc if there's no build going(I assume) on here?
How about the tfm based lib assets, but the sdks are not tfm based?

What's the VS UI experience long term?
How will this package be downloading, since the plan for download API #5919 is not yet nailed down implemented?

What's the target release date etc.

Per convention, the folder name has to be "sdk", if we're going the route of creating a asset group.
build/(S)dk.props is another option we can consider too.

[jeffkl]

@nkolev92 yeah we should probably have a quick meeting to discuss the implications here. There's a need to keep these packages out of normal search and possibly enforce more/less rules.

[natemcmaster]

Can you include me in this meeting? It may affect some of the engineering work we are planning for .NET Core.

[nkolev92]

Alright.

I edited the comment with more questions etc.

I just sent an e-mail to you, few mins ago.

[nkolev92]

Just putting up some notes from our earlier meeting.

The package type will be "MSBuildSdk", case irrelevant, since PackageTypes are case insensitive.

15.6

• The NuGet resolver on MSBuild side, will validate that only SDK package types are allowed. //cc @jeffkl

15.vNext:

• NuGet will consider the download API to allow the MSBuild resolver to avoid calling restore. NuGet Package Download API #5919
• Consider the handling of multiple package types, namely sdk + dependency This task //cc @natemcmaster
• Block MsBuildSdk Package types from search and appearing in the UI, based on the above decision Package applicability in NuGet package manager - Search & Update by TFM #5725
• Block those package types in restore This task

OOB (Server-side)

• Consider the package page details for SDK packages. The install/dotnet add pages should be different. //cc @rrelyea @skofman1 @anangaur
• Search changes/search by package type etc. Package applicability in NuGet package manager - Search & Update by TFM #5725

[nkolev92]

Is this relevant at all now?

I don't think the package type check was implemented on the msbuild side at all, making all of this moot.

I'd love to have that check, but I'm worried that it will break SDKs that never set this package type.

[jeffkl]

This is mostly needed for enforcement and search filters. We don't want people installing SDKs as normal packages and we'd probably want to be able to search for just SDKs or filter them out.

[nkolev92]

Is anyone actually creating the SDK packages with a package type?
If that's still true, then it's worth keeping :)

Is there a guidance for how to create these SDKs?

[jeffkl]

I set it in all of mine
https://github.com/microsoft/MSBuildSdks/blob/922c8d565383bacd6aecd4ad7739f7c821f15b2e/Directory.Build.targets#L26
https://github.com/jeffkl/KluGet/blob/6843fc75137e0e1e7dee418e1845fd635068a7d2/Directory.Build.targets#L37

And its set in MSBuild.Sdk.Extras which is widely used

https://github.com/novotnyllc/MSBuildSdkExtras/blob/de1a970a2f79b42935ba72e863dffe63dff3b21e/Tools/MSBuild.Packaging.targets#L4