The impact of Microsoft moving the base application to AL

Last week at directions Microsoft did a demo where they’ve shown the full solution running as an extension with only the system objects left in C/SIDE, that’s great, right?
In this blog, I’ll share my thoughts on the subject and make you aware of the impact it has.

Over the last few months, Microsoft has been preparing for this move, if you’ve been following the insider builds you might have noticed that they’ve separated the actual application code from the code that interacts with the platform (like codeunit 1), refactored those objects and moved them to the platform range (2000000000).

So why are they doing this? The answer is quite obvious, it’s time for C/SIDE to retire and focus on the modern development tools.
Let’s have a look at the roadmap to find out when C/SIDE’s retirement will become effective:

Next year Microsoft will finalize the C/AL to AL conversion and in 2020 it’ll be VS Code & AL only, which means end of life for C/SIDE.
This doesn’t mean you can’t use C/SIDE anymore with the older versions of NAV and BC, it just means that no effort goes to C/SIDE anymore.

What’s in it for us?

  • You’ll be able to take your customized base objects to AL
  • No more side-by-side development
    • AL-only.
    • Modern and attractive development environment, this will hopefully bring new people to the D365 BC world.
  • Developing directly on the source files
    • Native source control integration.
    • Easier to set-up continuous integration & continuous delivery.

Questions I have:

  • How will such a big extension perform, thinking of the time it takes to compile (I think this will be fine) and the time to publish the extension.
  • Migration path
    • Converting objects to AL: will export to new syntax and convert to AL do the job?
    • Migrating data: if the base app becomes an extension, how will we migrate the data from the C/SIDE tables to the tables provided by the extension?
      In general, migrating data from C/SIDE tables is not facilitated, the only option you have is to use upgrade codeunits to move the data to the fields added by your table extensions.
      This is do-able as long as you have a small solution, but let’s say you’ve customized the G/L Entry table and you’ve added a field, then you have to loop and modify every record in that table in order to get your data in.
  • How do we merge our customized base application with a new version once it’s converted to AL?
    • Can probably be done with any three-way-merge-tool, as long as we have the original, modified and target AL files?

Conclusion
Even though you’ll be able to take all of your lovely footprint to AL, it’s still really important to adopt a zero-footprint mindset, this saves you a lot of time when merging, upgrading etc.

If you haven’t started with reducing your footprint yet, here are a few tips to get you started:

  • Do not allow any new footprint, if you can’t get certain things done with events, find another solution or just don’t do it.
    This is the responsibility of the developer, so a call to all developers: take your responsibility!
  • Refactor your code to the event-based architecture, there are excellent videos available on the Dynamics Learning Portal where the event-based architecture is explained and applied in practice.
  • Create automated tests before you move ANY code, this way you’re sure everything keeps working as it should.
  • Move your customized pages to an extension, this is the easiest step to take since there’s no data involved.

 


Comments

  1. Hello Richard,
    you wrote : “This doesn’t mean you can’t use C/SIDE anymore with the older versions of NAV and BC, it just means that no effort goes to C/SIDE anymore.” and also “AL-only.” for 2020.

    I don’t think so , that we can use a modified base DB with BC-onprem in 2020. The Design Thinking of Microsoft is to used the same codebase on-prem and in the cloud and with intelligent edge it makes sense. So I think lately in 2020 Microsoft will not allow us to use a “Old School” modified database on-prem.

    I’m following a topic on yammer network regarding this statement.

    • Hey Arndt,

      Thanks for your reply!
      What I meant, is that you can still use C/SIDE with older versions of NAV and BC, like the Business Central Fall release (which still contains C/SIDE)
      It’s not like they will take it away also for already released versions.

      I’m sorry if it was unclear.

  2. Poul Lindholm Christiansen
    October 9, 2018 - 4:16 am

    “This is the responsibility of the developer, so a call to all developers: take your responsibility!” – you say.

    while I do think you are correct, that we as developers should start to design our solutions differently, lets not forget the Responsibility of Microsoft in this matter.
    It is their responsibility to continiously support their customers and their requirements – that is their responsibility as they take the clients money in the enhancement fee.

    So “Just dont do it” is not a solution for a client with an active enhancement subscription.

    • Hey Poul, thanks for your reply and I get what you mean.
      As a blogger, it’s always good to challenge people and I know that there are plenty of arguments against my statement regarding responsibility but if I would blog with all those arguments in my mind it would’ve been a bad read.
      Next to that I really think that this approach is also very well explainable to existing customers because they might want to upgrade in the future, right?

Leave a Reply

Your email address will not be published / Required fields are marked *