-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Source Generator projects don't need to be included in other library's sln files #58879
Comments
Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer Issue DetailsAny library that references System.Text.Json is getting the Json Source Generator project in their .sln file: Lines 54 to 55 in ef85762
runtime/src/libraries/Microsoft.Extensions.DependencyModel/Microsoft.Extensions.DependencyModel.sln Lines 24 to 25 in ef85762
runtime/src/libraries/System.Net.Http.Json/System.Net.Http.Json.sln Lines 28 to 29 in ef85762
These are unnecessary, bloating the .sln file. With #58446, there are now 2 .csprojs for each source generator - each targeting a different version of Roslyn. Which will make it even worse. We only really need the Source Generator projects in the .sln files of the libraries that build source generators: Json and Logging.Abstractions. cc @ViktorHofer
|
That is by design as solution files need to be dependency closure complete. If library A depends on System.Text.Json then the source generators of System.Text.Json need to be available in the solution as otherwise System.Text.Json isn't buildable. In other terms, VS requires all ProjectReferences (which represent the build graph) to be part of the solution. |
This issue has been marked |
I think this is where the disconnect lies. The System.Text.Json src project doesn't need the STJ source generator to be buildable. The only reason it has a "project reference" to it is for packing purposes. Because we want the source generator to be packed in the STJ nuget package. But to just build the System.Text.Json src project, the source generator isn't necessary. |
Just to double check, you are saying the System.Text.Json source generator isn't an analyzer input to the System.Text.Json source project? If not, then I question the existence of the ProjectReference (AnalyzerReference is a P2P) from S.T.J to the analyzer. That seems wrong. We should find a better way to express that an analyzer should be part of the shared framework. |
I took a closer look. Even though I was able to tackle the underlying problem with #69069, the change won't help with this specific issue. System.Text.Json ships as a package and includes the analyzers in it. Even though the analyzer is not a compile dependency, it's a package dependency which is expressed via the When I remove the projects from the solution and delete the obj and bin folders of the two source generator projects I hit the following issue:
I have been seeing this happen whenever a solution's dependency graph isn't complete. As said, even though the analyzers aren't a compile dependency, they are dependencies in the graph (an |
This issue has been marked |
Any library that references System.Text.Json is getting the Json Source Generator project in their .sln file:
runtime/src/libraries/Microsoft.Extensions.Configuration.Json/Microsoft.Extensions.Configuration.Json.sln
Lines 54 to 55 in ef85762
runtime/src/libraries/Microsoft.Extensions.DependencyModel/Microsoft.Extensions.DependencyModel.sln
Lines 24 to 25 in ef85762
runtime/src/libraries/System.Net.Http.Json/System.Net.Http.Json.sln
Lines 28 to 29 in ef85762
These are unnecessary, bloating the .sln file. With #58446, there are now 2 .csprojs for each source generator - each targeting a different version of Roslyn. Which will make it even worse.
We only really need the Source Generator projects in the .sln files of the libraries that build source generators: Json and Logging.Abstractions.
cc @ViktorHofer
The text was updated successfully, but these errors were encountered: