Open rainersigwald opened 7 years ago
I was talking to someone about this offline, but I've forgotten who. @piotrpMSFT, maybe?
I had done similar in my project! Here's the link if you're interested: MSBuild.Common.Sdk
folder in MSBuild-Sdks repo.
I wanted a single build tools kit for all my projects and I was inspired by .NET SDK and MSBuild.Sdk.Extras
!
Note:
MSBuild.NET.Legacy.Sdk
project was just an experiment to redirect the legacy props/targets to the Sdk package. The other packages are also an experiment to learn the old-stuff and try-out new stuff!Thank you @Nirmal4G for sharing your sdks! @jeffkl created the following repository for msbuild sdks: https://github.com/Microsoft/MSBuildSdks. Feel free to contribute.
In the v14 extensibility model, MSBuild distributed many props and targets as part of its own installer, SDK authors installed files into known locations, and project files imported props and targets using paths relative to the MSBuild install root.
With the advent of Sdks, projects no longer need to specifically specify a path but can address an Sdk by name and version. However, Sdks that wish to opt into common functionality (i.e. all Sdks) still import the core MSBuild targets by the old mechanism that assumes they are next to MSBuild, for example:
Instead, MSBuild could publish a "Core Sdk" containing a copy of these files, and Sdks could explicitly depend on a versioned copy.
That has two effects, after Sdk version identification is complete:
➕ An Sdk version reference is stable and should work identically on different MSBuild engines (barring changes in behavior). ➖ Merely updating to a new CLI/MSBuild doesn't get you the latest bugfixes/extensibility points from new common targets.