-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ApiCompat flags introduction of a base exception type for exceptions previously inheriting from System.Exception #32922
Comments
@dotnet/area-infrastructure-libraries a new issue has been filed in the ApiCompat area, please triage |
During an APICompat baseline comparison, assembly references passed in are ignored, which causes the sdk/src/ApiCompat/Microsoft.DotNet.ApiCompatibility/Rules/CannotRemoveBaseTypeOrInterface.cs Line 70 in e0a6431
Here's the code that disables loading assembly references for a baseline comparison:
There are two options:
Option no 2 is tracked via #18676 |
I don't really see it as incorrect, it is somewhat artificial, but it would be as if you were restoring the old version of the package, but applying any dependency updates that might have occurred in the new version. What's the worst issue you can imagine might happen due to this approximation? |
I could be wrong but APICompat's AssemblySymbolLoader might not be able to load some of the referenced assemblies and print a couple of assembly load errors. But as we don't validate versions, we might not see such a case. What about mixing assembly universes? I.e. the baseline package contains a netstandard2.0 asset and the current package contains only a |
I would expect every assembly referenced by the baseline to be present and an equal or higher version on the right. One case I can imagine is a dependency pushes a type down from A > B. Baseline referenced A, but A is no longer present in the current references. This is somewhat of an edge case and I think we'd be OK to allow it. I think we're improving this scenario by looking at references to begin with. Folks could always add the reference (which is techincally necessary for strict compatibility anyway). Concrete example of this might be a reference to Microsoft.BCL.AsyncInterfaces.
I don't think moving it forward should be a problem. The framework itself is compatible. In the netstandard2.0 -> net7.0 case we'll load the netsandard2.0 asset against the net7.0 surface area and facade and it should work. |
Describe the bug
ApiCompat check flags introduction of exception hierarchy:
was:
<Our Exceptions> --> System.Exception
proposed:
<Our Exceptions> --> Microsoft.Build.BackEnd.BuildExceptionBase --> System.Exception
error:
More details on the scenario: dotnet/msbuild#8779 (comment)
Build with failure: https://dev.azure.com/dnceng-public/public/_build/results?buildId=287532&view=results
The new base was introduced in assembly
Microsoft.Build.Framework
. The exceptions in the same assembly that underwent same refactors are not flaged. The change is flaged only in assemblyMicrosoft.Build
. HoweverMicrosoft.Build
referencesMicrosoft.Build.Framework
and the dependency is properly captured in the packages as well:To Reproduce
Introduce new base exception type that is defined in the referenced assembly
Further technical details
7.0.203
(https://github.com/dotnet/msbuild/blob/main/global.json)The text was updated successfully, but these errors were encountered: