-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
We need a repo convention to ship source generators as part of the ref pack #61321
Comments
Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer Issue DetailsI believe we want to ship the Regex source generator by default in .NET 7.0 I checked https://dev.azure.com/dnceng/public/_packaging?_a=package&feed=dotnet7&package=Microsoft.NETCore.App.Ref&protocolType=NuGet&version=7.0.0-alpha.1.21558.2 I believe because it is not built as part of the normal build that produces the refpack. This is because there is no We should update the docs to indicate what steps are required (if any additional steps are necessary): Possible fixes here are:
@stephentoub @joperezr @eerhardt @safern
|
cc @AaronRobinsonMSFT @elinor-fung in case they're also expecting the DllImport generator as well, since it's not currently in the ref pack. |
Thanks @ericstj. |
Thanks for logging this. I'll follow your first suggestion so that we can get the source generator into the ref pack as soon as possible so we can start getting feedback on it from more people. I'll also log a separate infrastructure issue to talk about conventions, so that we can use that issue to update all of the existing generators once/if a convention is decided upon. |
net6 comes with two generators, json and logging. not important for ref pack? |
Those are already in the ref-packs (JSON in the NetCore.App ref pack, Logging in ASP.NET). They both also ship packages and reference the source generator as part of their src project, which is why they aren't missing. This is about a new 7.0 generator for RegEx that was not included in the ref-pack. |
Can this be closed now, @joperezr? |
mm not really, if you see this comment It was decided that this issue would track coming up with a better convention of how to automatically add source generators to the ref pack so that the issue we had in regex wouldn't happen again. I don't think we have done that just yet, we only fixed the individual regex case. We should probably rename this one to match what it is being tracked, or close this and open a new one that tracks specifically the convention work. |
I've renamed the issue (despite breaking email threads 😆) to reflect what we are tracking. |
Fixes dotnet#61321 Until now we required source libraries to define ProjectReferences when an analyzer should be part of the shared framework. That strategy causes analyzer projects to leak into the ProjectReference closure and by that into a solution file. As an example: When another library references the source library that references the analyzer, the analyzer is part of the dependency closure even though it might not be required. This change makes it possible to define the shared framework analyzer projects in the NetCoreAppLibrary.props file for both the .NETCoreApp, and the AspNetCoreApp shared framework. Out-of-band projects which ship analyzers inside their produced package, continue to reference the analyzers via the `AnalyzerProject` item.
* Define convention to include analyzers in ref pack Fixes #61321 Until now we required source libraries to define ProjectReferences when an analyzer should be part of the shared framework. That strategy causes analyzer projects to leak into the ProjectReference closure and by that into a solution file. As an example: When another library references the source library that references the analyzer, the analyzer is part of the dependency closure even though it might not be required. This change makes it possible to define the shared framework analyzer projects in the NetCoreAppLibrary.props file for both the .NETCoreApp, and the AspNetCoreApp shared framework. Out-of-band projects which ship analyzers inside their produced package, continue to reference the analyzers via the `AnalyzerProject` item. * Use AnalyzerReference consistently * Don't reference analyzer when its packaged * Fix P2P reference * Fix multi target roslyn component target condition
I believe we want to ship the Regex source generator by default in .NET 7.0
I checked https://dev.azure.com/dnceng/public/_packaging?_a=package&feed=dotnet7&package=Microsoft.NETCore.App.Ref&protocolType=NuGet&version=7.0.0-alpha.1.21558.2
And noticed that it wasn't present.
I believe because it is not built as part of the normal build that produces the refpack. This is because there is no
AnalyzerReference
from the src project to the generator project and we have no convention to find and build generator projects as part of src.proj or ref.proj.We should update the docs to indicate what steps are required (if any additional steps are necessary):
https://github.com/dotnet/runtime/blob/331823f4046da1530dd950ac3ad8a87b3cdd584d/docs/coding-guidelines/libraries-packaging.md#netcoreapp-shared-framework
Possible fixes here are:
AnalyzerReference
to the shipping source generator.src.proj
to build the generator.generators.proj
.@stephentoub @joperezr @eerhardt @safern
The text was updated successfully, but these errors were encountered: