DotNet DataType and .NET Namespaces

[FSharpCSharp]

If possible, the DotNet data type should be available in some way. The call to WebServices, and the handling of XML documents, can not be solved with the available resources. It is very strange that DotNet was completely banned. There are already approaches such as "DOM management" or the "SOAP Webservice Caller". However, these are not enough to communicate with a complex web service, because different namespaces are a problem, or a different authentication must be given in the HTTP header.

In the current filing guidelines (for the AppSource), there is still DotNet present, but many namespaces are completely impossible like the System.IO where you can find the mostly used class MemoryStream. However, this MemoryStream already has more possibilities than the In- and OutStream available in NAV. Either one provides these classes, or there is a proper NAV stream. Furthermore, you can not specify a custom encoding of the file in NAV. There are only 3 possibilities to choose from, which are by far not enough.

Furthermore, there is no library for the rational handling of JSON. Here in the normal environment is Newtonsoft.JSON available. Why can not you use this library in Extensions? JSON is a quasi-standard for data exchange.

Under these circumstances, it is almost impossible to develop an interface that does not use standard SOAP, or whose structure consists of JSON.

Please make sure to do this, because otherwise it is a big step backwards for the development of NAV. With the help of DotNet, many things are much easier than in the NAV standard. This includes, among other things, the various string functions, a StringBuilder, which is 1000 times faster than strings with + to concatenate. Read XML using XPath, which is not available in the NAV standard at all, as well as much more.

[doivosev]

Thank you for your feedback because it help us understand the problems which you, developers, are facing when using our tools.
I hope everyone understands that we did not remove DotNet support because I broke up with someone from that team but because if we enabled direct DotNet usage we could not guarantee security and stability in a cloud environment where there are multiple users sharing the resources and some of them are potentially malicious.
We have recently released native Http and Json support and we are working on Xml support which will be released in the near future. The reason why we are doing it this way is because here we can add some safety checks behind these objects so that we can guarantee security and stability of the whole cloud. Behind these objects are actually Netwtonsoft.Json and DotNet HttpClient classes so you can use them as you would in C# but in spirit of AL mental model and code style.
Right after Xml we plan on adding support for other classes which you mentioned.

What we would like you to understand is that we are fully committed to enabling you the best possible development experience. We are not ready to sacrifice security and stability and I hope that you understand that we do not have infinite development resources so we have to prioritize.

You can help us by giving examples of use cases for the things you need when developing so that we can better prioritize.

Can you not use xmlport to communicate with SOAP web services and Json and Http to communicate with others? We support namespaces in Xmlports and you can have custom headers for various kinds of authentication with Http.

Here you can read more about Http and Json support:
https://blogs.msdn.microsoft.com/nav/2017/02/16/nav-development-tools-preview-february-update/

and here about XmlPort and Queries:
https://blogs.msdn.microsoft.com/nav/2017/04/21/nav-development-tools-preview-april-update/

[FSharpCSharp]

Thanks for the detailed answer.

I want to go through this in detail:

The justification that someone deliberately delivers malicious code always exists, even beyond the DotNet variable. To be quite sure you would have to check all the source text for correctness. If you now provide system functions for web requests, this is a start, but unfortunately, you simply follow the .NET standard in many ways.

About XML and XMLPorts. No what the standard XML port provides is only applicable for simple and simple maturity correct. It's true that you can now deal with namespaces, but CDATA is not possible for BLOBs and specific items like XPath. In addition, the creation of an XMLPort is not very user-friendly. This is much faster with Linq2XML or the standard XMLDocument class because you can access specific elements (XPath) without having to know the complete structure, or you can also extract elements.

We once had a requirement to call an XML-RPC service. We did not go with the XMLPort at all, because the structure was simply not properly reproducible. To this end, we still had to resort to the automation variables so that we could map the case.

About SOAP Webservices. Yes I said yes above already, that there are already started solutions, but that these in simple cases simply fail. Calling a service that uses HTTPS but does not use a general certificate (not publicly available, but only locally) can not be called. Similarly, services causing problems that retrieve the data via special operations that concern mainly ODATA-like constructs. Many services are installed locally at the customer, and not necessarily available in the cloud. And if the new Extension Framework is to be used on-premise in future, a solution must be available for this.

To the out-of-the-box JSON solution. Although the approach may be the right one, it simply lacks intuitive elements. Why are not C# similar elements like Lambda Expressions or Linq integrated in the AL language, if it is redesigned anyway. If I am in a JSON file through the tokens must rummage, then I have unfortunately won in the implementation nothing. Actually, a projection of a JSON file should be possible directly on a table or an object, similar to an XML port.

[Gallimathias]

Would not it be easier to drive parallel?

C # for the right developer and AL for the consultants?

It is not just about what is right and what is wrong. There are so many things I would like to do more comfortably than to bring AL regularly to its limits.

The wishes multiply here every day. If you implement everything is for the NAV-Team a lot of work. And while blood is licked by new features, but the people are dissatisfied because the release rate is lower.

And the wishlists are gigantic, because developers like me and @FSharpCSharp are spoiled by C #.

• Linq
• Pattern matching
• Complex Returntypes
• Attributes
• dynamic lists
• Interfaces
• abstract classes
• Reflection
• operator overloading
• base
• Method overloading
• Math functions (integral equations etc...)
• Own Controls
• cryptography (SHA512, SHA256, AES etc...)
• Streams
  etc.....

These are all things that can be retrofitted with .dlls. But will not be implemented in the foreseeable future in AL.

[FSharpCSharp]

OK I see one that may be a bit too much at once. But maybe you should think long term. Some of the language constructs like FOREACH have also gotten into the C / AL world. This has been really handy.

I'm not even doing it all worse than it is. But in the current NAV world, the data type DotNet was such a hermit between the two worlds. The consultant was able to use the required functions, For example, to integrate PDF and print into the program without having to deal with it in detail. And that is just what we simply lack. Another example. Why can not the format "Duration" almost be formatted with the standard NAV "FORMAT", while there are many possibilities for DateTime? Why can not you convert Date and Time and DateTime together very easily?

My fear is that many of the existing modules can not be reassigned to the new Extension Framework because there are dependencies to the outside. Again, here is an example: A customer would like that when he saves a document to PDF it is automatically signed. NAV offers no possibilities to sign PDF, or to save as PDF / A. Or what about the automated printout of PDF documents? NAV only offers the possibility to print Word documents automatically. For PDF, there is no integrated solution at all.

These are, in part, very important components which can not simply be replaced. I do not believe that NAV now also offers its own PDF library in order to make these possibilities available.

[esbenk]

For security reasons .net interop (and C#) will not be allowed in the D365 cloud.

Please read Vjeko's excellent blog about the topic.

[Gallimathias]

@esbenk If you put it this way. Does this mean then that we can continue to use .NET in the on premise solution in the future? This would be a very very important statement for us in Germany.

For 90% of our customers the cloud plays no decisive role. And for the cloud is no .NET ok. I can live with and I understand the backgrounds.

However, and here I am now even mean, I do not know what Navision currently makes more than cloud solution than the competitors.

The on premise solution, on the other hand, has a good reputation.

[esbenk]

.net interop will be supported on-prem.

[Gallimathias]

@esbenk With this statement you make me very happy :)

[Gallimathias]

No offense. I will still continue to build my own AL to C# compiler. XD

[FSharpCSharp]

OK, so summarized:

.NET, there will be only on-premise, but NOT in the cloud! This is definitely a decision from Microsoft. As a result, all solutions which can not be replaced by NAV means, as described above, fall away.

This means that if a customer buys a cloud solution and wants to print a 2D barcode on his / her documents, then it must be made clear that this is only possible on-premise, but not in the cloud.

Then, finally, a question in the developers of this round: Why is the use of .NET then problem-free in other Microsoft products? Is this the infrastructure, or the code runs in a sandbox?

How is the long-term planning regarding .NET Interop? Is it for sometime once thought, or it will definitely no longer be supported. This has, in my view, a great impact on all future cloud solutions, especially from a sales perspective.

[esbenk]

It is not possible to run .net on the Dynamics 365 servers due to security issues. Running .net securely in a multi-tenant environment is always hard. Azure-functions have put a lot of effort into this and in a way that isn't possible to reuse for the NAV stack. Even Azure functions doesn't allow everything from .net.

We plan to expand and extend the AL built library to support many scenarios where .net has been traditionally used by many partners.

I don't know how the mentioned 2D barcode support is built today, but I assume that the barcode could be generated outside NAV (e.g. in an Azure Function or another web-service) and be fetched using the new built in HttpClient support. That solution will work both for on-prem and the cloud.

We will continue to support .net for on-prem development.

[mortenseifert]

A suggesting would be to have AL support Azure functions as a native type. Now it would require implementing our own wrapper for each function.

[FSharpCSharp]

Will there be in the future in the development of an extension the distinction whether this is intended for on-premise or for the cloud? Because logically, the on-premise extension should also be done with the new Visual Studio code.

How is the further development regarding the system functions conceived? Is it possible to submit concrete applications, which are always given in normal business life, and Microsoft checks whether these are included in the standard language?

[esbenk]

Visual Studio Code will also be the development environment for on-premise.

We are investigating how we can improve the developer experience with Azure Functions. We don't have concrete design or timelines at this point.

We have asked a number of partners for their .net usage and checked our own codebase and used that as initial input for prioritisation. First batch is focusing on calling external services from AL e.g. HttpClient and Json.

You are also more than welcome to suggest features here on Github.