Personalized Community is here!
Quickly customize your community to find the content you seek.
Check out the latest Business Central updates!Learn about the key capabilities and features of Dynamics 365 Business Central and experience some of the new features.
Overview | Guided Tour | Free Trial
2023 Release Wave 1Check out the latest updates and new features of Dynamics 365 released from April 2023 through September 2023
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
I’ve received a request from a partner asking why adding a return value to a procedure in a Dynamics 365 Business Central extension that previously had no return value is considered a breaking change during AppSource validation.
The explicit question was: “if previously I had a dependent extension that uses the first version of this procedure (the version without return value) and now I add a return value to the procedure, the dependent extension should not be broken because it simply ignores the return value. I know that you cannot change the type of the return value or remove it, but why adding a return value is a breaking change?“.
To better explain the scenario, imagine to have published a version 184.108.40.206 of an app with a procedure like the following:
In a new 220.127.116.11 version of our app, we add a new return value to the procedure, like in the following example:
If you validate the new version and you check breaking change from the first version, you will have the following result:
error AS0102: It is not allowed to add a return value to procedure 'DemoProcedure' on object 'SD Demo Codeunit', because it might break dependent extensions at runtime.
What does that means?
Breaking changes on extensions can be summarize as per the following types:
In this case, we have a runtime breaking change. Adding a return type to a procedure that previously had no return type changes the internal method ID used by the server runtime to call the function. If the dependent extensions referencing the procedure are not recompiled, they will use the old method ID and this will cause runtime issues due to the ID mismatch (you can have errors like “function ID in object XX cannot be found“).
Please remember this and also remember to always validate your apps before submitting. You will catch lots of these errors.
Business Applications communities