📝 Guidance for what an Sdk looks like

[rainersigwald]

What makes a good Sdk? What functionality must it provide? Should it always include Common.targets? Should we define a new minimum target surface?

What do dependencies look like?

Must every Sdk have both props and targets? Should an Sdk define a version-number that can be used in other Sdks for error checking?

We should pull heavily from the experience of the existing Web and NET Sdks, but temper that with understanding that they were originally defined for something else.

Later edits:

• the following page contains samples of msbuild sdks, as well as links to documentation: https://github.com/Microsoft/MSBuildSdks

[gulshan]

MSBuild SDKs are very similar to plugins in Gradle. So, we can have a look on their description of plugins-
https://docs.gradle.org/current/userguide/plugins.html

[cdmihai]

A point to consider: what is the difference between SDKs and "normal" PackageReference packages that bring build logic? Both of them lead to extra top and bottom imports, but via different mechanism (sdks have msbuild awareness whereas build augmentor PackageReferences use the common props / targets extensions).

When should users use one against the other?

[borgdylan]

I have a related use case: bringing in a compiler with targets inside a package that depends on the Sdks installed by the dotnet CLI tooling. How will that work?

[cdmihai]

@borgdylan

With the current implementation, I don't think there's a way to have a node in the PackageReference closure depend on a node in the SDK closure. With the way the current design is going, you'd have to make a third party SDK with the compiler logic, and have it depend on some other SDK (though the following are not yet supported: third party SDKs, inter-SDK dependencies, SDK closure, and on the fly SDK acquisition).

This is because PackateReference is an item, and items are only evaluated in msbuild after imports and properties. Since the SDK closure is computed in an earlier step of the evaluation, you can't have a thing from the future influence a thing from the past (the SDK version constraint of a PackageReference node affecting the dependency resolution in the SDK graph).

[borgdylan]

I do not wish to write an Sdk myself. I'd rather import targets (that I will write) from a path based on the package root property that is already available by filling in a property in the Sdk that comes with the CLI. The .NET Sdk happens to require a property that points to the targets for a compiler i.e. the Sdk already lets third party languages participate.. I just wanted to know if there will be an official story or if I could just hack my way to something that works.

[dsplaisted]

@borgdylan Take a look at dotnet/sdk#539. I think if we do that, you will be able to have a compiler in a NuGet package by setting the LanguageTargets property to a .targets file in your NuGet package in the auto-imported Build\<PackageName>.props file.

[borgdylan]

So far language targets has worked for me when setting a hard coded path(I'm still authoring the targets). Once the bug regarding netxy targeting is fixed on non windows I'll try the nuget route as well.

[enricosada]

@borgdylan see FSharp.NET.Sdk package, works really well to add F# support using LanguageTargets (thx to @dsplaisted ).

About sdk, ihmo can be useful to customize some behaviours, mostly related to restore i think:

• override or customize restore target to use another nuget client (like Paket /cc @forki)
• include of <PackageReference dinamically
• languages
• evaluation of project pre-restore

[borgdylan]

If LanguageTargets works OK now, I won't need to write an Sdk but only targets files. I don't use Paket with my custom language but normal NuGet.

[enricosada]

@borgdylan paket doesnt matter, was an example of configuration of sdk.

For language yes, afaik, you can just use a PackageReference (who contains a props file with the LanguageTarget property set).

I used an sdk for F# because like that i can enable dotnet pack with multiple <TargetFrameworks> too.

[borgdylan]

Shouldn't that work automatically without writing an Sdk? Why does the language specific support have to drive multi-targeting builds?

[bbowman]

@borgdylan @enricosada I'm a little confused following this discussion. How is the LanguageTarget property coming into play here? My team https://github.com/Microsoft/WinObjC is currently just using a nuget package for our compiler + sdk and I want to understand the implications here.

[Nirmal4G]

I have been developing experimental SDKs for my projects.
Here's the MSBuild-Sdks repo that I currently hold these SDKs.

They are experimental, bit of mixed from existing projects, props, targets and some my own to get my projects going. some might not build properly.

But I hope these will provide some insight on what I was hoping to achieve! and possibly give a standard for SDKs design! Also #1686 (comment)