Re-enable ApiCompat ref<->src assembly validation #81104
Conversation
|
Note regarding the This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change. |
|
Tagging subscribers to this area: @dotnet/area-meta Issue DetailsIn https://github.com/dotnet/runtime/pull/81080/files#r1085327303, we noticed that ApiCompat doesn't emit an error for public API differences anymore between the contract and the implementation. While Package Validation still ran and validated implementation assemblies, non packable projects were not correctly validated. This regressed on Dec, 14th 2022 with 1529058 which enabled ApiCompat for the linker tooling. I moved a property from a props to a targets file which resulted in ApiCompat's ValidateAssemblies feature to not run. The first part of this fix is to move the property back into a props file and adding a comment to warn about moving that property to a different evaluation order. The ApiCompat.proj baseline changes are expected. The baseline lists all the public API differences between 7.0.0 and 8.0.0.
|
|
LGTM for the System.Linq side. |
| @@ -37,25 +37,18 @@ public partial class EnumerableQuery<T> : System.Linq.EnumerableQuery, System.Co | |||
| } | |||
| public static partial class Queryable | |||
| { | |||
| [System.Diagnostics.CodeAnalysis.RequiresDynamicCode("Enumerating collections as IQueryable can require creating new generic types or methods, which requires creating code at runtime. This may not work when AOT compiling.")] | |||
There was a problem hiding this comment.
Are these because we generally don't include RequiresUnreferencedCodeAttribute in ref files? Or these actually don't exist in the src?
|
CoreLib is failing because locally you usually only compile against one but CI validates all of them. Will send a fix. |
ghost
locked as resolved and limited conversation to collaborators
In https://github.com/dotnet/runtime/pull/81080/files#r1085327303, we noticed that ApiCompat doesn't emit an error for public API differences anymore between the contract and the implementation. While Package Validation still ran and validated implementation assemblies, non packable projects were not correctly validated.
This regressed on Dec, 14th 2022 with 1529058 which enabled ApiCompat for the linker tooling. I moved a property from a props to a targets file which resulted in ApiCompat's ValidateAssemblies feature to not run.
The first part of this fix is to move the property back into a props file and adding a comment to warn about moving that property to a different evaluation order.
The second commit fixes the API compatibility differences that happened since Dec, 14th:
The ApiCompatBaseline txt changes are expected. The baseline lists all the public API differences between 7.0.0 and 8.0.0.