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?

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.