Dynamics F/SCM Customer Experience (CRM) Dynamics GP Dynamics Business Central (NAV) Dynamics SL Power Platform Fabric Copilot

[Gregory Alford]

Has anyone started the migration to extensions?

——————————
Gregory Alford
ERP Manager
Tri Star Metals LLC
Carol Stream IL
——————————

[Marije Brummel]

Yes, I’ve started the migration of one of my largest customers. I’ll share my experiences at NAVTechDays in Antwerp in November.

Unfortunately I could not get funding this year to attend NAVUG Summit.

I can say that it works fine as long as you create smaller extensions for each isolated sub-solution. We currently have 8 extensions running on a hybrid C/Side system.

Performance is not an issue and the JavaScript ControlAddIn architecture opens up a whole new world of possibilities.

We also started using the new API and replaced some customizations with this.

The NAVTechDays session will be published on YouTube. You can always contact me for details.

——————————
Mark Brummel
NAVUG All-Star
–
ForNAV
Olst
——————————
——————————————-

[Jason Wilder]

Mark, you are doing this on NAV 2018?

——————————
Jason Wilder
Senior Application Developer
Stonewall Kitchen
York ME
——————————
——————————————-

[Samuel Champoux]

?What about this comment from this page: https://docs.microsoft.com/en-us/dynamics-nav/how-to–develop-an-extension

“Do not add inline comments to your code. Such comments are helpful as internal documentation, but they will cause the extension to fail when you build the extension package.”
It seems to me like this shouldn’t be a thing.

——————————
Samuel Champoux
IT Director
Drummondville QC Canada
——————————
——————————————-

[Jon Long]

Inline documentation is unnecessary and adds to unmanageable code.

——————————
Jon Long
Director of ArcherPoint-Upgrades
ArcherPoint Inc.
GA
——————————
——————————————-

[Jon Long]

To expand on this, code should be written so that it is easily understood, “self documented”. I don’t believe documentation that explains what the code is doing is necessary at all. Date stamps, developer initials, partner tags. None of that is of interest to me. I’ve never needed it to write or update code. So, where would “documentation” be appropriate? In source control. Even then, it would be high level, not a description of why the code was written a certain way.

Source control documentation is really all you need.

That’s my opinion. I’ve experienced nightmare in-line documentation scenario’s where the documentation actually makes it harder to understand the code. It get’s worse over time as upgrades make wholesale changes in functionality and the original author of said documentation is gone. I delete the documentation in these cases. I’ve also seen really messy merge issues, simply with inline comments. These messes are perpetuated over time. So, I’m not a fan.

——————————
Jon Long
Director of ArcherPoint-Upgrades
ArcherPoint Inc.
GA
——————————
——————————————-

[Marije Brummel]

This only applies to extensions V1. You can add comments to V2.

——————————
Mark Brummel
NAVUG All-Star
–
ForNAV
Olst
——————————
——————————————-

[Marije Brummel]

Yes, NAV2018 RTM.

——————————
Mark Brummel
NAVUG All-Star
–
ForNAV
Olst
——————————
——————————————-

[Val Gameiro]

I’ve just started using extensions in Business Central. It’s C/AL code, but they now call AL. The code seems to be the same, but there’s new structures and functions to learn.

You’re still adding objects in the 50K range, but you can also extend existing objects via the new triggers. Pretty cool, but there’s a bit of a learning curve.

So, in this case it’s not a move to extensions, but starting out in extensions.

Looking forward to see what comes up with 🙂

——————————
Val Gameiro
Advanced Business Systems, LLC
Implementer/Project Manager
Austin, Texas
former NAVUG Austin Chapter Leader
——————————
——————————————-