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.
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
Sdkfolder and contain two MSBuild project imports namedSdk.propsandSdk.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.