AL
AL copied to clipboard
microsoft
A few DotNet-objects most commonly used by a partner (us)
Here are some of the DotNet-objects we're currently using, for future reference. It would be quite helpful to be able to use these in the future in AL, since DotNet-support is keeping us from migrating to Extensions.
-
System.IO.MemoryStream used with File.ReadAllBytes
-
System.BitConverter (ToString) used with System.Security.Cryptography.SHA256Managed (512 works too)
-
System.Convert for Base64-handling
-
System.Web.HttpUtility for HtmlEncode and HtmlDecode (xml)
-
System.String for replace-functionality w/ others, System.Text.Encoding used for charset handling with File.ReadAll and File.WriteAll. System.Environment for .NewLine etc
-
System.IO.DirectoryInfo for looping folder contents by pattern, using System.Collections.Generic.IList`1, System.Collections.IEnumerator and System.IO.FileInfo. RunOnClient-version used as well.
-
System.IO.Path and System.Diagnostics.Process for finding NAV client, ClientPath := FORMAT(Process.GetCurrentProcess().MainModule.FileName); ClientFolder := SysIO.GetDirectoryName(ClientPath) Used to Process.Start() client with separate parameters (debug etc). RunOnClient-versions used as well.
-
General arrays necessary for many of the above: System.Array and System.Collections.ArrayList; System.Collections.Generic.Dictionary
2 with System.Collections.Generic.KeyValuePair2
1,3. Look at points 6 and 7. For MemoryStream you can have a look at the implementation here cal-open-library 4. HttpUtility has already been discussed in #1042. 5. string has already been implemented extensively as text. here Regex is in the discussion 6,7. FAQ. For security reasons, the File API is currently not available in App development. 8. you have dictionaries and lists since the following update natively: October Update (0.10.13928 - 2017/10/12)
Regarding point 7 (running a process via system.process). You need to re-evaluate this decision. I understand that launching a server-side process should be off-limits for security reasons, but to eliminate launching a client-side process?
sample use case:
I have a client who has a .NET windows forms app they use for dispatching service orders to field technicians (it's visual & very drag-and-drop friendly, much more efficient than the service dispatching capabilities that ship with NAV). The client launches this app from NAV itself (via a codeunit menu item).
Please reconsider - there may be valid use cases to launch a client-side process from Windows RTC that do not conflict with Microsoft's security concerns.
@SteveKrisjanovsD365 Did you found any workaround in launching other processes from within the webclient?
@atoader Regarding point 7, any change on having this re-enabled in a later update? We have the exact same need. Our 'Planning Tool' is - currently still - an external .NET based solution - installed locally. Users have a shortcut (via a codeunit menu item) via the RTC client. Looking for alternatives in the webclient...
@fvet with the removal of the Windows Client, it will not be possible to re-enable this functionality. We will provide guidance on how you can use local client functionality with a cloud installation of BC.
@fvet in the year since I last posted, I've abandoned .net entirely and moved to http rest calls.
It's more overhead since I have to write additional middleware than I used to but that is the price to pay for SaaS.
As for calling client functionality from the cloud, I use a combination of http rest and websockets.
E.g.
[BC SaaS] >> http rest >> [custom http middleware] >> websocket message >> [custom websocket client]
Hi, this is a rather old (compound) suggestion, with some of the entries available or less relevant.
As this GitHub is for tracking bugs in AL Language and VSC VSIX, we will close this suggestion. If still applicable, consider adding support to the System app or log individual entries on https://aka.ms/bcideas to allow others to vote on the suggestions
