* Use analyzers from targeting pack for NetCoreAppCurrent
Fixes that analyzer failures didn't show-up in #74897
Add analyzers to the frameworklist that OOB projects in src/libraries
use, and only auto ProjectReference the analyzers in generators.targets
when not using the analyzers from the targeting pack.
Also move the generator projects related code into a separate file.
Continuation of https://github.com/dotnet/runtime/pull/75093
* Fix project build
* Add missing reference to Regex tests
* Add missing generators for netfx build
* Fix paht in test project
* Fix typo
* Disable runtime marshalling for SharedTypes.csproj
* Disable runtime marshalling for NativeExports.csproj
* Try to untangle the rid calculation.
* Ignore __portableOS.
* Add back musl detection.
* Try fix AnyOS tests.
* Try fix coreclr linux_musl_arm64 job.
* src/tests/build.proj: use PackageRID for restore.
* Use RuntimeOS as an override for _packageOS.
* Remove (probably) out-dated override for non-portable ToolsRID.
* CI cross-builds for linux-musl use linux.
* Add missing arch to rid.
* Try simplified ToolsRID.
* Update comments.
* Rename OutputRid to OutputRID.
* Tweak comment.
* Move TargetsLinux{Bionic,Musl} with the other Targets properties.
* Don't use RuntimeOS for PackageRID for CrossBuilds.
* Move RuntimeOS condition to ToolsRID assignment.
* Clean up a few things.
* Fix broken Condition.
* Try fix the linux-bionic build.
* Try fix the linux-bionic build, part II.
* Try fix the linux-bionic build, part III.
* Fix PackageRID.
* Use RuntimeOS as _packageOS override.
* Remove RuntimeOS.
* Fix '-os linux-musl' mapping.
* Clean up .
* Rename __PortableOS to __PortableTargetOS.
* Extend comments.
* Extend OutputRID comment too.
* build.sh: include linux-bionic, linux-musl in usage.
* SourceBuild.props: no need to pass RuntimeOS. Only set ToolsOS, PackageOS when RuntimeOS is not empty.
* Fix comment.
* linux-bionic doesn't get built on linux-bionic.
* Unconditionally assign TargetsLinuxBionic/TargetsLinuxMusl.
* Remove SkipInferTargetOSName.
Follow-up on #32451
Follow-up on #80074
In #43651, the "Windows" OS name was lowercased to achieve target frameworks with RIDs in them. At that time, the original plan was to lowercase all TargetOS values but that had to be cut because of resources. This PR finishes that and updates build systems, YML, markdowns and managed components.
To not break existing developer workflows, the passed-in -os value is automatically lower-cased in the script entry points and validated in the msbuild entry point.
* Use shipping runtime.json for RID targeting
- Use the shipping runtime.json file to target RIDs when building
instead of the custom OSGroups.json which only contained a subset of
the available rids.
- To facilitate that, lower-case the existing platforms in the target
frameworks strings which is the expected format anyway by the SDK and
msbuild. This will eventually make it possible to bring some of the
custom build infrastructure back into the SDK.
- Remove a few outdated code pieces and update docs.
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" />
```
* 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
Split the build of shared framework and out-of-band projects so that
it's possible to just build the shard framework projects, which was
requested by the CLR teams. In the next infrastructure rollout, the
current "libs.ref+libs.src" subsets should be removed. Generate the
targeting pack with an incomplete (without shims) frameworklist as part
of the "libs.sfx" subset.
Build the shim projects after the shared framework and oob projects and
re-generate the targeting pack's frameworklist to include the shims.
Refactor the shims so that they aren't grouped anymore by generated &
manual. Instead group them by "ref" and "src" same as other libraries
in the tree which allows to reference the source project shims and read
from the ReferenceAssembly metadata.
Use ProjectReferences in traversal projects and shim projects instead
of named references that point to binplace directories (see graph below)
This allows to build parts of the product dynamically, i.e. the shim
projects, apicompat.proj, sfx.proj and oob.proj.
* Don't use Targets* helper properties in libs projs
This change makes it possible to migrate 200+ (ref+src) projects to use
TargetFramework instead of TargetFrameworks which avoids the additional
outer build evaluation and invocation which ultimately makes the overall
build faster.
Targets* properties (i.e. TargetsWindows, TargetsAnyOS, TargetsUnix,
etc.) rely on the TargetFramework property which usually are set
inside a project. The TargetFramework property is only
available before a project specifies it if it's explicitly set in a props
file or if the project is cross-targeting and the outer-build dispatches
into the inner-build. During the dispatch, the TargetFramework property
is passed in as a global property.
Until now that behavior wasn't a problem because every libraries project
cross-targeted (by setting the TargetFrameworks property) even though
many only include a single TargetFramework (i.e. NetCoreAppCurrent).
To allow projects to use the TargetFramework property instead of
TargetFrameworks, the Targets* helper properties can't be calculated
anymore early in a props file as the TargetFramework property isn't set
at that time.
In general, the guidance by the SDK/msbuild team is to not read from the
TargetFramework property before the project sets it
(in a property group). That effectively means that the TargetFramework
property shouldn't be used in props files at all.
Therefore these helper properties can't be used anymore for property
conditions and I'm replacing their usage with TargetPlatformIdentifier
comparisons for both properties and items.
In nearly all cases, the Targets* helper properties can be replaced with
TargetPlatformIdentifier checks on items and in the few cases where
TargetsUnix or TargetsLinux marks multiple tfms as compatible, the exact
tfms must be used instead for the TargetPlatformIdentifier comparison.
Whenever a project needs to condition properties on the platform, I'm
first setting the TargetPlatformIdentifier the same way the SDK sets it
so that the SDK later doesn't need to set it again to avoid the
additional expensive msbuild function call.
* Use TargetFramework singular to avoid outer builds
Use TargetFramework instead of TargetFrameworks property whenever a
projects only targets a single target framework. This avoid unnecessary
outer builds and evaluations and makes the build faster.
* Enable System.Text.Json tests on netfx
* use NETFRAMEWORK define
* disable another two test cases after rebase
* disable last test case which repros only on CI for me
* add p2p only on netfx
* 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.
* Remove EOL tfms and upgrade to net7.0
* Make linker tests net7 aware
Make installer tests run on net7.0
Don't attempt to use live apphost
Fix payloads
Regenerate test files
Fix package testing
* 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
- Remove depprojs which currently binplace external references into the RefPath folders in favor of PackageReference and PackageDownload items.
- Build all configurations by default when building an individual project (either on the CLI or inside VS) same as with the official SDK. This enables .NETFramework Test Explorer support.
- Centrally define libraries that compose the shared framework instead of in each Directory.Build.props file to be able to build the targeting pack first and consume it in the OOB libraries.
- Use ProjectReferences to reference OOB projects. Compile against the reference assembly but use the implementation assembly app-local during runtime.
- Remove OOBs from the testhost and remove the testhost folder for .NETFramework as it isn't required anymore.
- Only binplace for $(NetCoreAppCurrent) to compose a) the targeting pack, b) the runtime pack, c) the testhost, d) a full closure for the shims.
- Use Targeting Packs for OOB projects (with their implicit assembly references) but still explicitly define granular references for .NETCoreApp configurations (DisableImplicitAssemblyReferences switch). Use the implicit targeting pack references in some Microsoft.Extensions.* cases.
- Remove placeholder configurations as they aren't needed anymore with explicit P2Ps vs Targeting Pack references.
- Remove implicit assembly references (ie for .NETFramework, mscorlib)
- Remove AssemblySearchPath hacks that were introduced with b7c4cb7 as the targeting pack is now used by default.
- Reduce unnecessary .NETFramework configurations that were added to run tests in favor of the already existing ref&src configurations.
- Stop hardcoding the paths for wasm assemblies and use the returned TargetPath of the ProjectReferences.
- Addressed formatting (ItemGroups, References at the bottom of the project file, ordering of references, use LibrariesProjectRoot instead of a relative path, unnecessary AssemblyName and RootNamespace properties which are identical to the project name, ordering of tfms)
- Revert "fix clean (#33758)"
Viktor Hofer
Tom Deseyn
Eirik TsarpalisandViktor Hofer
Jan Kotas
Andy Gocke
Krzysztof Wicher
Aaron Robinson
Eric Erhardt
Anirudh Agnihotry
Larry Ewing
Jeremy Koritzinsky