- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Binary API Breaking Change in 108.0.2 #1953
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
Comments
You're right. I would gladly accept a PR where the method is reverted, and the new overloaded is added with options. Then, I can release it as a minor under 108. |
I can do that after work :) |
It wasn't as easy as I expected because of the optional parameters. So, it will be one more breaking change, but the impact would be only on people who use the options, and I don't think this feature is widely used. |
ah thanks! |
No worries, I hope I can release it soon, so you can try. |
Btw you can try the latest preview to make sure it works as expected. |
Hey Alexey! I may have to try with a full open API gen with dotnet core, but at the very least locally it, with a binary ref and a proj ref, it works! |
Noice, I will tag that version and release it. |
I am getting this using Xero XeroAPI/Xero-NetStandard#472 |
On 110.2.0 I also got this error while using Xero.NetStandard.OAuth2Client (1.6.0) |
@Jacko1394 v110 is a major version so it is not expected to be binary compatible. |
Describe the bug
The following change:
c969747?diff=split#diff-fd5240c0eeb1a04bc0c9ea9b5210c8a8ce6703011459c72d49ee4b0c08e61224R292
Introduces a default parameter to a number of extensions (
FileParameterOptions? options = null
)Binaries previously compiled against the old version (lacking the default arg) will fail to find the method at runtime.
(see this answer on SO)
What will result, will be a runtime binding exception:
To Reproduce
a. Expose that code path
Expected behavior
The method works succesfully
Stack trace
n/a
Desktop (please complete the following information):
n/a
Additional context
It is important that the assembly produced in step 1 is referenced as binary not as source (project), since its a binary breaking change, not a source breaking change.
The code of the assembly A would still compile, if REcompiled against version 108.0.2, it is the runtime binding that would fail.
The text was updated successfully, but these errors were encountered: