This happens if you have a table object, saved with a post-GDPR CU (Like NAV2018 CU6), imported that object into a pre-GDPR NAV and then try to export it to TXT from that version. Post-GDPR objects include the DataClassification properties
Make sense? Post-GDPR objects are not compatible with Pre-GDPR NAV CUs.
The solution, do not mix your development environment. Currently, that means that CU2 is the preferred CU for NAV2018 development.
(The quick fix, is the remove the fields, and RETYPE them (Cut’n’Paste will not work).
I’ve seen a couple of explanations about this, but they seemed incomplete, so I did this quick write-up.
This is part of a very old C/Side bug, (or feature might some people from Microsoft argue) where unknown properties are carried along behind the scenes when importing FOB files.
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 🙂