1
0
Fork 0
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:
Viktor Hofer 2022-05-12 09:22:26 +02:00 committed by GitHub
parent 35e47797a3
commit d3af4921f3
Signed by: github
GPG key ID: 4AEE18F83AFDEB23
20 changed files with 137 additions and 94 deletions

View file

@ -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>
```

View file

@ -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.