AArnott / CodeGeneration.Roslyn

Assists in performing Roslyn-based code generation during a build.
Microsoft Public License
408 stars 59 forks source link

Create SDK package #113

Closed amis92 closed 4 years ago

amis92 commented 5 years ago

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

Features

A project built with this SDK would:

And possibly other needed additions.

Additional ideas

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

AArnott commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 (https://github.com/AArnott/CodeGeneration.Roslyn/pull/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 https://github.com/NuGet/Home/issues/4013 and https://github.com/NuGet/Home/issues/3604 where the NuGet team specifically prevented recursive package restores to prevent various issues.

AArnott commented 5 years ago

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 commented 5 years ago

Some links I read so I don't forget:

amis92 commented 4 years ago

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

AArnott commented 4 years ago

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 commented 4 years ago

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.