-
Notifications
You must be signed in to change notification settings - Fork 252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create new package type for MSBuild project SDKs #6484
Comments
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? What's the VS UI experience long term? 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. |
@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. |
Can you include me in this meeting? It may affect some of the engineering work we are planning for .NET Core. |
Alright. I edited the comment with more questions etc. I just sent an e-mail to you, few mins 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)
|
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. |
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. |
Is anyone actually creating the SDK packages with a package type? Is there a guidance for how to create these SDKs? |
I set it in all of mine And its set in MSBuild.Sdk.Extras which is widely used |
In MSBuild 15.6 (dotnet/msbuild#2803), we shipped a NuGet-based project SDK resolver that allows users to specify something like this:
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 namedSdk.props
andSdk.targets
.Example:
However, there's nothing technically wrong with a package containing reference assemblies, runtime assemblies, build logic, and an SDK.
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.
The text was updated successfully, but these errors were encountered: