I use Extensions and Visual Studio Code in my daily life. Or at least for a while, nowadays it’s more something in my weekly life. I try to avoid them when I can.
Not because they are bad or evil but because they slow down my productivity, and because I have legacy software.
Almost everyone I talk to agrees that programming extensions is slower and more clumbersome than C/Side. Not just the first few weeks.
When Extensions were first shipped I was stronly against the way they were architected. Microsoft simply slapped to existing pieces of technology together with a PowerShell sauce and sold it as the best thing since sliced bread.
It was even sold as being the only way to have decoupled code.
This, my friends, is where I think it went wrong.
With C/Side it is possible to have decoupled code, but it is not possible to have decoupled tables and pages. Only if you keep the delta files, which is the artifact Microsoft used as one of the ingredients for Extensions.
If Microsoft would support Table Extensions and Page Extensions in C/Side and if they would disable access to existing objects C/Side would have the same technical capabilities as Visual Studio Code.
It would in fact be capable of doing much, much more… I’ll get back to that.
Visual Studio Code has native Git integration. True. I’ll give you that. I’ve used it a lot but I have yet to find the true value compared to exporting text files from C/Side and moving them to Git manually.
With Visual Studio we cannot debug a live system, or look at an existing object. There is no solution for XMLPort Extensions or Report Extensions nor can you simply replace existing objects with new ones.
Legacy & Monoliths
The true difference between Visual Studio Code and C/Side is how the solution is managed. Both tools have intellisense and can handle thousands of objects. If you create and maintain an Angular project in VSCode you’ll see that your project easily contains more objects than you can oversee.
Which is where the value of C/Side is imminent. Where Visual Studio Code expects you to only edit a handful, maybe up to 100 files, C/Side allows you to easily navigate accross every file in the solution and change everything.
Visual Studio Code is designed for modern decoupled applications that take dependencies on packages.
This is where we get challenged because NAV, Business Central or Navision (I don’t care how you call it) Is not a decoupled application. It’s a monolitical dinosaur that requires years to master and was never designed with decoupling in mind.
Most ISV solutions are also monolitical applications because we took the habbits from Microsoft and designed our solutions in an identical way. Microsoft must do it right, so let’s do it like they do.
I don’t blame you for making that choice. I did the same and it is the very reason I decided to keep working in C/Side. The solution I work with every day has over 2000 objects. Even though these objects are not depending on the Microsoft objects it is very hard to manage them in Visual Studio Code. You actually realise how smart object numbers are and how easy they make C/Side work once you don’t have them anymore.
Visual Studio Code & Decoupling
VSCode is designed for smaller, decoupled projects. You can work with multiple projects open at the same time, but they work best when separated.
To get the most out of the VS Code experience you need to refactor your solution in multiple extensions and figure out the dependency schema.
Which is a shitload of work and who has time for that.
The Other Difference…
There is another difference between Visual Studio Code and C/Side that makes it valid for Microsoft in my opinion to keep C/Side alive.
Imagine the scenario a few paragraphs ago. Imagine C/Side with a Table Extension object type and a Page Extension object type. That would make both environments identical rithg?
No… actually it would give C/Side a huge competitive advantage to Visual Studio Code.
Financials Object Files…
Aka Fobs… Tell me how many times you only change two objects in a database that has 8.000 objects or more. Or just one.
How do you ship them? Exactly, you just export the file using C/Side.
If my solution with 2.000 objects were one big extension shipping small changes would become a nightmare. We all have a DTAP system but how often do you make a fix in Test so the tester can continue? How many of you have a Hotfix database? More scary; how many of you just make a change to a report or a page in Production?
Microsoft Keep C/Side Alive!
For Microsoft to make Business Central in the Cloud succesful they don’t need to do away with C/Side.
The new generation of Cloud developers (if they exist, I only see NAV partners jump on it) never see C/Side.
On the other hand, if Microsoft would move base-NAV to Visual Studio Code we would all take a huge step back.
Navigating in 5.000 or 10.000 file project in Visual Studio Code is a freaking nightmare and compiling and shipping the whole monolith for one report would make customers run away to the competition in a fraction of a second.
Great, so now what…
So Mark, you say Microsoft has to keep C/Side because of the way NAV is designed, because it is not decoupled. Yes, that is what I am saying.
And this is where it becomes freakingly dangerous what I am about to say.
Let’s be the devils advocate…
If you are forced to refactor or redesign your monolithical applications into decoupled microservices, why would you per-se do it in AL?
That my friends, is where and how we will continue this blog series by talking about things like the API, CDS, PowerApps, Asp.Net Core and Angular.
Yes, I choose to stay with Microsoft, but you are correct if you think you might as well switch to any other framework as long as it is a web-framework. The latter is important if you want to embed with Business Central, the best cloud solution out there today.
SPOT On.. This is exactly what I have been saying for Months to myself, and weeks to others. Working on projects with 100 of objects in “one vertical” is simply not that doable as it is to just “demo” how cool the new development environment is.
All these “lets learn the new environment blogs” simple don’t tell you all the complicated issues we are facing. And most tell me that I am just an grumphy old man – Indeed I am, but I am also very much aware of the competitors of Dynamics NAV and what they do… they are clapping their hands right now.
Simple issues as you mention – small updates of single or few objects are becoming a nightmare, group development sounds cool, but reality strikes soon, when everybody figures out all the stuff that is no longer possible (as easy as today). Remember that, day where you did group development, and found out that only one person can debug at a time pr. servicetier?? You where probably quite surprised as I was.
VSC-development is NOT the bright new future , at its current state – right now its a small candle – a lot of work needs be be done before this even comes close to what the “classic development environment” can do, or as fast. Opportunitits says VSC-is way faster than “classic” – I am still laughing.
Well, it just might be because I have not fully understood what is going on behind the curtain or below in the engine room of NAV.. I doubt it though. I think Microsoft really needs top step up and start explaining how, and not at least when simple issues are going to be solved when switching to Dyn365bc.
Any customer that currently wants to go online to Dyn365bc – go ahead, but use it as is.. do not ask for any changes except small layout issues.. wait for the next “release” later this year. The product is cool, but the technology could be better, and we simply have to wait for that to happen
LikeLiked by 2 people
An excellent article, well written and reasoned.
Couldn’t agree more. Yes, C/SIDE has a lot of antiquities. But VS.Code+AL isn’t up to the challenge of moving ALL our work into (yet). Where else can you update one single class? Where else can you import an update to an object AS THE OBJECT IS BEING USED and user sessions will automatically switch over to the new code (once the old version goes out of scope)? I too said from the start that developing in C/SIDE isn’t going anywhere soon (not this year in any case, we’ll see what 2019 brings us).
LikeLiked by 2 people
Please Microsoft, listen to him.
LikeLiked by 1 person