Create SDK package

[amis92]

Summary

The SDK package would be used instead of the Microsoft.NET.Sdk Sdk by default, or in addition to it:

<Project Sdk="Microsoft.NET.Sdk">
  <Sdk Name="CodeGeneration.Roslyn.Sdk.Generators" />
  ...
</Project>

Inspired by PR #108 by @jarrodldavis

Problems solved

• Packaging generator as NuGet for redistribution

Features

A project built with this SDK would:

• provide preset TargetFramework see first comment
• setup NuGet packaging accordingly to be used by CodeGeneration.Roslyn's dotnet-codegen:
  • add build/package-name.props that include required additions (https://github.com/AArnott/CodeGeneration.Roslyn/blob/d8afd59f1698b45549cd0e7850a645629677fb6f/README.md#packaging-up-your-code-generator-for-others-use)
  • set the property IsTool, DevelopmentDependency and NoPackageAnalysis to true

And possibly other needed additions.

Additional ideas

It's possible that there would be additional SDKs (just ideas):

• CG.R.Sdk.SdkPackage that'd help create Sdk package for a custom generator
• CG.R.Sdk.Test that'd help in unit testing the custom generator
• CG.R.Sdk which would replace BuildTime package - this would probably "fix" the version conflict for customers using generators that depend on different (but compatible) CG.R versions, as the given SDK has to have only one version in a solution (and project), declared by the customer himself in global.json.

[AArnott]

provide preset TargetFramework

No, I don't think so. VS has an implementation detail that depends on that property being set within the project file itself. Otherwise it'll load the project with the wrong project system in some cases.

[amis92]

Ahh yes, hacks and details. Besides TargetFramework, I think that DotNetCliToolReference also has weird behavior, as it works when included in project file or Directory.Build.props, and yet it doesn't when being added as part of build/<pkg>.props - I guess the restore won't run twice.

Will keep that in mind. Maybe a check with warning then. So, other than that, any suggestions? I'm very much not happy with names. All of them sound weird. Especially the possible CG.R.Sdk.SdkPackage.

[jarrodldavis]

I think that DotNetCliToolReference also has weird behavior, as it works when included in project file or Directory.Build.props, and yet it doesn't when being added as part of build/<pkg>.props - I guess the restore won't run twice.

I think I remember running into that issue when initially trying to package up a generator and part of what led to my (admittedly convoluted) double-SDK solution in my pull request (#108). DotNetCliToolReference seems to work fine when included as part of an SDK.

Edit: yes I remember after a lot of spelunking through NuGet issues finding stuff like NuGet/Home#4013 and NuGet/Home#3604 where the NuGet team specifically prevented recursive package restores to prevent various issues.

[AArnott]

No other suggestions at this point.

I'm very much not happy with names. All of them sound weird. Especially the possible CG.R.Sdk.SdkPackage.

How about CG.R.Generator.Sdk?

[amis92]

Some links I read so I don't forget:

• https://docs.microsoft.com/en-us/visualstudio/msbuild/how-to-use-project-sdk?view=vs-2019
• https://docs.microsoft.com/en-us/dotnet/core/tutorials/cli-templates-create-template-pack

[amis92]

A rewrite of the Plugin.Sdk is happening at #198.

[AArnott]

The SDK package would be used instead of the Microsoft.NET.Sdk Sdk by default, or in addition to it:

Please make it in addition to it. There can only be one top-level SDK, so if too many cool features want to be "the one", a project can't use more than one of them.

[amis92]

It's done as such. I'm also going to make it usable as a normal PackageReference as well, because it seems the MsbuildSdks still have poor support across tooling (looking at you, Omnisharp).

When used as a normal package, all props and targets will be the same, except there'll be no implicit PackageReference of CodeGeneration.Roslyn.