Closed amis92 closed 4 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.
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
.
I think that
DotNetCliToolReference
also has weird behavior, as it works when included in project file orDirectory.Build.props
, and yet it doesn't when being added as part ofbuild/<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.
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?
A rewrite of the Plugin.Sdk is happening at #198.
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.
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
.
Summary
The SDK package would be used instead of the
Microsoft.NET.Sdk
Sdk by default, or in addition to it:Inspired by PR #108 by @jarrodldavis
Problems solved
Features
A project built with this SDK would:
provide preset TargetFrameworksee first commentbuild/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)IsTool
,DevelopmentDependency
andNoPackageAnalysis
totrue
And possibly other needed additions.
Additional ideas
It's possible that there would be additional SDKs (just ideas):
global.json
.