Al: Just a thought on DotNET Interop

[markbrummel]

I know the whole DotNet interop is a delicate subject, but I still just wanted to let this brainfart out and get some feedback.

Yes, you can do weird stuff with DotNET like probably format the c-drive of the azure machine but you can also use it for clean code.

An example.

I was asked to import sales invoices from TT Line (you guys in Denmark probably know these ships). We receive them as XML.

Yes, I can create an XML Port and yes, I can use the Data Exchange Framework, and yes I can probably use the new AL XML Types.

BUT!!

In Visual Studio I can paste the XML as an object and with three lines of C# code move the file into the class. With DotNET Interop I can wrap this dll into a variable and code against a strong object.

How is this harmfull to azure? This is clean code and easy to write. I don't take any dependencies on NuGet packages and the AL code I write you guys convert behind the scenes to C# code anyway.

Why cannot I write simple C# code inside my extensions. Not rocket science but just simply leveraging a strong programming language that AL is already based on and converted into.

I would understand if GitHub is not the place to discuss this but I simply cannot get my head around this limitation.

[Gallimathias]

Mark, I completely agree with you. That shouldn't surprise anyone. We have heard it here on GitHub in several issues several times by several people already. So far the argumentation has always been security, but I think this chain of argumentation is only an excuse. There are solutions to this problem. If you look over to the AX guys then they can also program in DotNet and are also in Azure. In general it is worthwhile to compare the two worlds again and again because here much is similar in terms of the problems but was technically solved differently, sometimes better, sometimes worse.

Lately I see the really big problem with AL both here in the company and on GitHub. Adding to these constant requests for changes in terms of events or extending functions paralyzes the whole project. It would be better to rely on a concept like inheritance so that we won't be overwhelmed by conceptless events and functional changes that individual companies need right now. Then the hard linking of AL with the NAV product, we cucumber with the AL versions afterwards because the product is slowing us down, it would be better if compiler and language could develop without the application having to be released. Simply update the compiler (server) at the customer and always get the latest version of the extension from the marketplace would be so much cooler.

And last but not least, while we are on the subject of change requests, we have already had this discussion before, I think it's crazy to claim that the customer wants a functionality that will then be implemented and may be included in the next release. In the end in AL is so many things missing, I don't know if all this can be replaced if you really only want to set to AL. I mean, .NET has next month 18 years on its hump and has something like 14,000 classes available and consists of no idea how much line of code.

Yes, the goal may not be to make AL fully-fledged, but sorry, it has to be compared with other programming languages, even if the database only contains C# code and no one is interested in the AL code from the app table anymore. But this leads to the question why do you do things the way you do in AL or NAV?

Somtimes I wish to talk to the people behind NAV (AL) to get answers to my questions and understand why things are the way they are in AL/NAV, but as Mark said, maybe GitHub isn't the right place to discuss this kind of questions.of questions.

Maybe I am only very young and want to change the world. Anyway, that's definitely my opinion to the topic or my support for @markbrummel .

[erikrijn]

I don't understand the aversion some people seem to have to any form of change. There's a perfectly valid mechanism in place to do anything you like. You can create (micro)services outside of the application. You can still use your c# code, or python, or nodejs, or php, or.... you get my point. There is no need to bring back the old slow reflection-based dotnet variables inside of AL. The fact that Microsoft is now considering bringing it back for the on-prem version of BC makes me sigh in disbelief. They are once again giving into invalid complaints. This way, they will never get to where they want to be. Wasting precious development resources to please a select few that can't deal with changes.

[Gallimathias]

@erikrijn I have nothing against change. The old dotnet variables were not a good solution, that's not something I want back. But I want flexibility, I want freedom and not the current restrictions. I don't use DotNet variables if I can do the same with AL, but we are currently really far away from it. Apart from that, in the case of the dotnet variables not the reflection was the problem with the performance but other things.

10% of my wish list for AL is somewhere in one of the first issues.

To say something about (micro)-services: They were already used before AL, such services are cool and powerful. Solve some problems, but also open up new ones. (Micro) services are not a panacea. And many things cannot be solved via (micro) services. (Funfact: Network connections are slower than reflection. So wen you will bring the Performance Argument, Network lose the compedition)

But yes, I agree with you, there is no point wasting development resources to make people happy who can't cope with change. We fully agree on that, and I have already mentioned that. The other side and there is the problem with the too slow or dotnet thing. I am faced with concrete problems that do not work with AL and cannot be solved with (micro)-services, answers are expected from me and I would like to say in my answers "Heey people we still use AL", I do not want to stick to the old glue because of such challenges.

But Heey, if the right things happen in AL when you notice it's going on. But it need big steps in the language or Statments from Microsoft. What could help for future discussions? A simple Roadmap or vision or a hint from the official kanbanboard for the AL Language (not Dynamics, only AL). The very big Question is what is the current Target for AL. Which functions can I count on, where should the trip for AL go? And there would also be a few decisions on fundamental questions of interest, e.g. that and that will never exist or that and that is currently so but our goal is that. Yes, then I will gladly do without DotNet. And believe me, I will support everything I can to prevent C/al in the future in projects.

[erikrijn]

My problem is with Microsoft's lack of sticking to their vision and roadmaps. First they say, 'no more dotnet!'. Fine, we all start redesigning our code-bases and put a lot of effort and time into that. Just to later find out that they once again start buckling under the pressure when they receive complaints from a select few. As always, a few people with complaints are the loud voices in the community, while you won't hear the people who are happy with the tools at their disposal. My biggest fear right now is that they will start supporting c/al again in the on-prem version. That would kill their vision and I will start looking elsewhere if that happens.

[yrest]

@erikrijn I would tend to agree with your complaint about Microsofts' potential sudden change of plans, however I totally do understand those changes of plans, because there are customers who have no intentions to go anywhere outside of their premises and they demand flexibility and extensibility of their solutions, which neither AL nor microservices (on premises) can provide as easy as pure dotnet. I have a feeling we might be underestimating how few those "a few people with complaints" and what value do they have for Microsoft as a business. That does not make me a fan of bringing c/al back into the mainstream (even though I love c/al), but makes me a huge supporter of dotnet interop for whatever they come up with.

[StanislawStempin]

Thank you for more feedback on the .NET topic.

There is no change in strategy from our side.
We have been saying from the beginning of the AL project that DotNet will be available On-Premise but will NOT be available in the Cloud.

No developments in the technology landscape have so far enabled us to reconsider enabling DotNet in the Cloud. I cannot go into more details but, among others, security and resource governance issues still disqualify DotNet for use in a multi-tenant cloud solution. Comparisons with other Microsoft products are in most cases not accurate since those other products are either not multi-tenant, isolate .NET execution behind a network-hop or don't have the same cost considerations as Business Central.

We are going to great lengths to enable the support for On-Premise with the goal of helping all partners and customers to bring their solutions to AL. Using DotNet will still mean that such a solution cannot be published in the Cloud but at least it helps make the first step of being based in the modern stack of AL and extensions.

We are aware of many useful scenarios that could be enabled by .NET in BC Cloud but coming up with more examples of such scenarios unfortunately doesn't change anything with regards to the reasons for the original decision.

So to sum up and as we have been always communicating:

• DotNet interop in AL will be available On-Premise
• DotNet interop in AL will not be available in the Cloud