ArcherPoint Dynamics NAV Developer Digest - vol 290
The Dynamics NAV and Business Central community, including the ArcherPoint technical staff, is made up of developers, project managers, and consultants who are constantly communicating, with the common goal of sharing helpful information with one another to help customers be more successful.
As they run into issues and questions, find the answers, and make new discoveries, they post them on blogs, forums, social media…so everyone can benefit. We in Marketing watch these interactions and never cease to be amazed by the creativity, dedication, and brainpower we’re so fortunate to have in this community—so we thought, wouldn’t it be great to share this great information with everyone who might not have the time to check out the multitude of resources out there? So, the ArcherPoint Microsoft Dynamics NAV Developer Digest was born. Each week, we present a collection of thoughts and findings from NAV/BC experts and devotees around the world. We hope these insights will benefit you, too.
The New V5 AL Extension – Errors and Warnings
Bill W shares: “The new V5 AL extension has hit the marketplace, and you might notice a TON of new warnings. Use the filter in the problem section to narrow it down to errors/warnings/info.”
Figure 1 – Filter issues and warnings in Dynamics 365 Business Central
Matt Street suggests: “But the question is, which ones can we ignore because they will be relaxed later, versus which ones will stick and be required for any sort of standard or approval for AppSource? We need to have a company policy on which rules we should strive to comply with at ArcherPoint. What good is automated analysis if we choose to just ignore the ‘rules’ and end up bad code? Just ignoring it seem to violate all the Defensive Programming tips I learned from Matt Traxinger.”
Kyle wants to know: “Why would we use a newer version? Shouldn’t that always match the exact build you are developing for, pulled either out of the container or from the installation media?”
Bill replies to Kyle: “On premises, perhaps that’s what you should do. There is a runtime setting in app.json that will allow the extension to compile different targeted versions. The ‘promise’ is that you can use the one extension to develop against any runtime, but that hasn’t really panned out well. If you’re developing for AppSource then you’ll want to be in the latest and greatest. As far as we can figure, the rules in the latest extension are what they compile against and accept/reject based on this first pass.”
Bill then replies to Matt S: “It’s handy to get things compiled short term. There will be another version of this extension I would think, based on this issue report in Github. Some of these warnings are nonsense, for instance:
‘The record RPMRShippingReceivingLine should be modified before saving to the database.’
I’m definitely modifying it before saving it to the database. There are hundreds of rules and literally thousands of lines of AL code that these rules may or may not apply to. I’m not sure we can create a policy to address this.”
Matt Traxinger responds: “I see no change to current procedures. Our same rules still apply. Your goal is to get a clean compile with no warnings and obviously no errors. That said, when new versions of AL come out, we can’t in good conscience go spend a bunch of time correcting all of these:
Procedure 1 – The Boy Scout Rule. Leave your campground (object) cleaner than when you found it. If you touch an object with warnings, you are at the very least expected to clean up the warnings in the area you touch. Your warning count should be reduced, or worst case stay the same, every time you do a check in.
Procedure 2 – Request a Change. If there is a warning you think shouldn’t apply, ask about it. We can hide warnings that don’t make sense from the compile. Don’t just arbitrarily do this; think of it as a code review type of thing or asking Microsoft to put a new event in their code. It should be a deliberate, conscientious step to ignore these.
Ultimately, we all share collective ownership of every extension we put out there. It’s all of us working together to make those extensions incrementally better every time, even if Microsoft sets us back every now and then.”
Matt Street follows up: “Hence my suggestion for an ArcherPoint Code Cop standard. Which warnings and info messages are we willing to forgive for now and say it is acceptable to have this warning, versus which rules to we want our developers to strive to resolve? Yes, there are always critical needs that may be the exception, but I agree that some of these are over the top and even to the point that they cannot be fixed. But we should have some consistent standard we are striving for.”
Matt S responds to Kyle: “But then what happens when they upgrade? The goal should be that our development will protect them from having to do a lot of modifications to be able to upgrade to a later release.”
Matt T responds to Matt S: “No, you should always map the AL version to the BC version. There can be new keywords and other things that just aren’t compatible. It’s potentially the equivalent of developing a modification in 2018 for a customer on 3.6.”
Kyle adds: “Until they make it so that we can add table keys that reference base table fields, there will always be warnings.”
If you are interested in Dynamics NAV and Business Central development, be sure to see our collection of NAV/BC Development Blogs.
Read the “How To” blogs from ArcherPoint for practical advice on using Microsoft Dynamics NAV and Dynamics 365 Business Central.