mirror of
https://github.com/VSadov/Satori.git
synced 2025-06-08 03:27:04 +09:00
Define convention to consume and/or package analyzers (#69069)
* Define convention to include analyzers in ref pack Fixes https://github.com/dotnet/runtime/issues/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
This commit is contained in:
parent
35e47797a3
commit
d3af4921f3
20 changed files with 137 additions and 94 deletions
|
@ -14,7 +14,7 @@ In some occasions we may want to include a library in the shared framework, but
|
|||
|
||||
Libraries included in the shared framework should ensure all direct and transitive assembly references are also included in the shared framework. This will be validated as part of the build and errors raised if any dependencies are unsatisfied.
|
||||
|
||||
Source generators and analyzers can be included in the shared framework by specifying `IsNetCoreAppAnalyzer`. These projects should specify `AnalyzerLanguage` as mentioned [below](#analyzers--source-generators).
|
||||
Source generators and analyzers can be included in the shared framework by adding their project name into the NetCoreAppLibrary.props file under the `NetCoreAppLibraryGenerator` section. These projects should specify `AnalyzerLanguage` as mentioned [below](#analyzers--source-generators).
|
||||
|
||||
Removing a library from the shared framework is a breaking change and should be avoided.
|
||||
|
||||
|
@ -70,10 +70,10 @@ Build props and targets may be needed in NuGet packages. To define these, author
|
|||
|
||||
Some packages may wish to include a companion analyzer or source-generator with their library. Analyzers are much different from normal library contributors: their dependencies shouldn't be treated as nuget package dependencies, their TargetFramework isn't applicable to the project they are consumed in (since they run in the compiler). To facilitate this, we've defined some common infrastructure for packaging Analyzers.
|
||||
|
||||
To include an analyzer in a package, simply add an `AnalyzerReference` item to the project that produces the package that should contain the analyzer
|
||||
To include an analyzer in a package, simply add an `AnalyzerReference` item to the project that produces the package that should contain the analyzer and set the `Pack` metadata to true. If you just want to include the analyzer but not consume it, set the `ReferenceAnalyzer` metadata to false.
|
||||
```xml
|
||||
<ItemGroup>
|
||||
<AnalyzerReference Include="..\gen\System.Banana.Generators.csproj" />
|
||||
<AnalyzerReference Include="..\gen\System.Banana.Generators.csproj" Pack="true" ReferenceAnalyzer="false" />
|
||||
</ItemGroup>
|
||||
```
|
||||
|
||||
|
|
|
@ -188,6 +188,7 @@ All test outputs should be under
|
|||
|
||||
## gen
|
||||
In the gen directory any source generator related to the assembly should exist. This does not mean the source generator is only used for that assembly only that it is conceptually apart of that assembly. For example, the assembly may provide attributes or low-level types the source generator uses.
|
||||
To consume a source generator, simply add an `<AnalyzerReference Include="..." />` item to the project, usually next to the `References` and `ProjectReferences` items.
|
||||
|
||||
## Facades
|
||||
Facade are unique in that they don't have any code and instead are generated by finding a contract reference assembly with the matching identity and generating type forwards for all the types to where they live in the implementation assemblies (aka facade seeds). There are also partial facades which contain some type forwards as well as some code definitions. All the various build configurations should be contained in the one csproj file per library.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue