search

NuGet / Home

Repo for NuGet Client issues
Other
1.49k stars 250 forks source link

Create new package type for MSBuild project SDKs #6484

Open jeffkl opened 6 years ago

jeffkl commented 6 years ago

In MSBuild 15.6 (https://github.com/Microsoft/msbuild/issues/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 commented 6 years ago

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 https://github.com/NuGet/Home/issues/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 commented 6 years ago

@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 commented 6 years ago

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

nkolev92 commented 6 years ago

Alright.

I edited the comment with more questions etc.

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

nkolev92 commented 6 years ago

Just putting up some notes from our earlier meeting.

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

15.6

15.vNext:

OOB (Server-side)

nkolev92 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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