Sorry for the click-bait title. But I have just tried out the new developer preview on one of our (Currently) C/Side ExtensionV1 based products. This article is not really about that, but about one of the positive side effects of going through the process.
First disclaimer: This product already compiles to an ExtensionV1 and is CfMD certified, so of cause it is perfect 🙂
But the new compiler and the TXT2AL transformation tool will find things that can be improved, let me show you some of the results I got:
Properties not used on actions
RunPageMode is only valid if you have a RunObject also:
Since I use OnAction() RunPageMode does not do anything.
DecimalPlaces on non-decimal fields
BlankZero on non-number fields.
C/Side accepts wrong Indention
You can place ActionGroups outside ActionContainers.
Assignment of FlowFields
C/Side accepts this, and ignores it; the new compiler gives an error.
Wrong keys on Actions
In multiple places, you can specify sortings, and C/Side happily accepts “Field###” – Extensions don’t.
There are many more things that this process can catch, but these examples were some I encountered.
You can improve the code quality of your existing solution by running it through the TXT2AL and the new compiler. And when you’re ready to jump to ExtensionV2, the jump will be easier and smaller.
Finally Extensions V2 supports DotNet (At least in the Developer Preview.
But as soon as you fire this up, perhaps with the help of TXT2AL, you’re met with assemblies not resolved. Both assemblies from standard DotNet (from the global assembly cache) and standard NAV DLLs.
There is a setting in Visual Studio Code (In User Settings Ctrl+Comma) called al.assemblyProbingPaths that specifies where Code will search for DotNet assemblies (Also called DLL files). Add the Global Assembly Cache and the add-ins folder from a NAV installation to resolve all the references:
"C:/Program Files/Microsoft Dynamics NAV/110/Service/Add-ins"
Restart Visual Studio Code and everthing should work 🙂
When Microsoft announced that DotNET support was being discontinued in the modern development environment, many of us had issues with it. I still believe that it was a too drastic approach, but that’s not a focus of this blog post.
A bit later, Microsoft announced the “CAL-OPEN-LIBRARY” – A GitHub repository for wrapping dotnet classes in codeunits.
It can be found here https://github.com/Microsoft/cal-open-library The basic idea, is that you can write a codeunit that wraps a DotNet class and submit that to Microsoft for consideration for future products, so I did 🙂
One of the DotNet classes I use all the time, is the MemoryStream, a stream you can both write to and read from, and that holds the data in memory (hence the name).
I wrote a codeunit with the functions I needed, with tests and submitted that as a pull request.
And when NAV2018 came out, codeunit 704 has appeared:
There is my wrapper, all ready to go.
Lots of other people, incl. several MVPs, have also added contributions to the cal-open-library, go check it out. And the next time you’re missing something, contribute, it works 🙂