* Avoid package dependencies on libraries in the shared framework
We can avoid these dependencies since we can count on the library being
part of the shared framework. Fewer dependencies means less packages
downloaded, less for customers to service, less copied into the output
directory when serviced.
* Add warning code.
* Address feedback
d3af4921f3 made it possible to reference
and package an analyzer via the same msbuild item by setting custom
metadata.
While reviewing other places that could use the AnalyzerReference item,
I realized that using this custom item doesn't provide much value and
creates an artificial difference to the rest of the stack and our customers
[as we don't adhere to our own documentation](https://devblogs.microsoft.com/dotnet/introducing-c-source-generators/#hello-world-source-generator-edition).
Instead, IMHO it makes much more sense to keep using a
`ProjectReference` item with the documented set of required metadata, to
reference an analyzer and just define an additional custom metadata to
support packaging the analyzer: `PackAsAnalyzer`.
The reason for that is that the additional metadata explains how the
reference works (no assembly output reference, added as an Analyzer
output item) vs. the `AnalyzerReference` which is a repo custom item
that doesn't tell you that behind the scenes it actually gets converted
to a `ProjectReference` with the same metadata as if you would declare
that yourself as a P2P.
To summarize the change:
1. Consume an analyzer
```xml
<!-- Before -->
<AnalyzerReference Include="..." />
<!-- After -->
<ProjectReference Include="..." ReferenceOutputAssembly="false" OutputItemType="Analyzer" />
```
2. Pack an analyzer and consume it
```xml
<!-- Before -->
<AnalyzerReference Include="..." Pack="true" />
<!-- After -->
<ProjectReference Include="..." ReferenceOutputAssembly="false" OutputItemType="Analyzer" PackAsAnalyzer="true" />
```
3. Pack an analyzer without consuming it
```xml
<!-- Before -->
<AnalyzerReference Include="..." Pack="true" ReferenceAnalyzer="false" />
<!-- After -->
<ProjectReference Include="..." ReferenceOutputAssembly="false" PackAsAnalyzer="true" />
```
* Fix typos
* Cleanup trailing whitespaces in committed files
* Revert a macro for win32 compat
* Disambiguate test data method
* Revert XMLPath test which rely on external assets
* Revert whitespace change in Xml tests
* Revert ClrEtwAl and ILLink.Shared
* Revert crossgen2 props/targets and *.wxl
* 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
* Only add placeholder pkg file if folder is empty
Originally reported in https://github.com/dotnet/runtime/issues/63413,
placeholder files are added unconditionally by the .NETStandard compat
error packaging infrastructure, even if the
buildTransitive/$(SupportedTFM) folder isn't empty.
That hinders our libraries to package their own set of buildTransitive
props and targets files for the supported set of tfms.
This change makes sure that placeholder files are added only if no None
or Content items are declared that point to the same package folder.
Adding documentation that explains the .NETStandard compatibility
packaging infrasturcture and how to correctly package hand-authored
msbuild files next to the generated targets files.
* Fix NETStandardCompatError empty cases
* Update packaging.targets
* Remove .NETStandard runtime implementations
Remove the remaining ten .NETStandard runtime specific implementations.
For reasoning please see https://github.com/dotnet/runtime/issues/64536.
* Remove infra support for NS platform specific tfms
Also cleaning-up some logic and stop disabling AppendTargetFramework.
* Respond to feedback in GenerateMultiTargetRoslynComponentTargetsFile
Two small follow up changes from #58446
- Fix a type-o that breaks incremental build. Forgot to use MSBuild property syntax
- Instead of having the infrastructure hard-code removing 'Abstractions', packages can set their own Disable source gen property name.
* PR feedback
* Simplfy .NETFramework tfms
Libraries which target .NET Framework usually have rid agnostic tfms,
i.e. net461. If the library targets netstandard2.0-windows as well,
the .NET Framework tfm must be rid specific, as rid specific
.NET Framework apps would otherwise pick the .NETStandard asset over
the .NETFramework one (based on the RID compatibility rules)
There is yet another reason that requires .NETFramework tfms to be RID
specific, which is when a project P2Ps other projects which are
rid-specific. Without the RID specific .NETFramework tfm, a compatible
.NETStandard asset would be picked instead.
NuGet doesn't support setting a TargetPlatform in the TargetFramework
alias when targeting .NETFramework or .NETStandard. Any such tfms in
dotnet/runtime are currently leveraging a hack that strips the
TargetPlatform / TargetFrameworkSuffix away during restore and packaging
(as NuGet Pack uses the project.assets.json file).
As NuGet will likely never support RID specific .NETFramework tfm
aliases, the distinction between a RID specific and a RID agnostic
.NETFramework tfm is unnecessary.
Remove all "TargetFrameworkSuffixes" / TargetPlatforms / RIDs
(whatever you would like to call them) from .NETFramework tfms and let
the packaging targets handle the cases where a RID specific asset is
required in the package.
Explictly don't set TargetsWindows to true for .NETFramework builds as
the Targets* properties are infered from the platform / suffix and
many projects make the assumption that net461
(without the "-windows" part) doesn't set TargetsWindows=true.
Fixes https://github.com/dotnet/runtime/issues/58495
* Warn on .NETFramework duplicate runtime assets
* Ignore .NEtFramework non Windows and non empty RIDs
Also cleaning up the packaging.targets file and removing
the ExcludeFromPackage option which isn't needed anymore as
target frameworks aren't excluded from packages produced in
dotnet/runtime anymore.
* Rename transport packages to follow convention
As agreed on in https://github.com/dotnet/windowsdesktop/pull/1936, we
want to follow a common schema when naming our transport packages.
Also updating the docs to reflect the name changes and to also
accomodate for the WindowsDesktop transport package.
* Update src.proj
* Update src.proj
Use ProjectReferences to compose the aspnetcore tranport package.
Avoid binplacing and with that unnecessary copies which overall
simplifies the infrastructure and allows to add additional transport
packages without creating a binplace configuration for each.
This also makes sure that the dependencies are compatible with the
package's tfm.
* Clean-up pkgproj leftovers in libs and apply fixes
Remove any pkgproj infrastructure that was only used by src/libraries
(which is the majority). Delete the packageindex *YAY*.
Update the documentation that covered the packageindex and the pkgprojs.
Avoid any incremental builds during packaging by removing
libraries-packages.proj and use src.proj for packaging instead. Make use
of the `GeneratePackageOnBuild` property to build package during the
allconfigurations without requiring a different entry target.
Fix the addition of the DocumentationFile during packaging when
`GeneratePackageOnBuid` is used by hooking onto the
`DocumentationProjectOutputGroup` that NuGet uses and replacing the
generated documentation file with the one that comes via the
intellisense package.
Also introduce a property to choose the generated documentation file
over the one from the intellisense package:
<UseIntellisenseDocumentationFile>false</UseIntellisenseDocumentationFile>
Removing a few leftover PackageDescription properties from the projects'
Directory.Build.props file.
Cleaning up properties in Directory.Build.props & Directory.Build.targets
files.
* Actually run packaging during the allconfigurations build
* Update docs
* make runtime specific pkgs non packable
* io.ports native pkg fixes
* Expose missing refs from runtime in targeting pack
The platform analyzers warns for usages of APIs which aren't available
on specific platforms. Exposing the missing reference assemblies which
are already part of the runtime pack in the targeting pack.
The big benefit of doing so is that customers don't need to reference
the corresponding packages to target these APIs and that these five
packages can be dead-ended.
For more in-depth reasoning, see the detailed summary:
https://github.com/dotnet/runtime/issues/53892#issuecomment-858542280
Fixes https://github.com/dotnet/runtime/issues/53892
* Update dependents of dead-ended packages
Update depents by referencing the latest available package. Making sure
that packages are never used on NetCoreAppCurrent by applying
.NETCoreApp version conditions.
* Fixes
* Remove pkg validation suppression file
* Update Windows Compatibility pack
* Fix DirectoryServices pkg references
* Fix netfx Pkcs restore/build
* Fix version conflict
* Packageindex and nits
* nits
* Include NetCoreAppCurrent configs in packages
The NetCoreAppCurrent configurations were omitted from packages to avoid
ever growing packages. Now that we adhere to the support policy for
packages we don't need to exclude them anymore as the policy defines a
baseline for .NETCoreApp configurations.
This will remove an artificial difference when source building the
repository and also make it so that partner repositories which don't
depend on a transport package like windowsdesktop (winforms) receive
the very latest assets that are included in the shared framework as
well.
* Fix package validation for non exposed inbox libs
* Add Analyzer packaging support and packaging documentation
To package Microsoft.Extensions.Logging.Abstractions we needed support
for packing an Analyzer. This adds that support.
I wanted to document this addition, so I created the start of a doc that's
meant to describe the packaging options for libraries in dotnet/runtime.
* Address code review feedback.
* More feedback
* Address more feedback
* Remove src.proj build of generators
* Update to use Microsoft.DotNet.PackageTesting
* Fix typos
* Fix package testing on net46*
