Converting an ISV solution to an extension: Update 1

Well, what can I say……….this is going to take a while. 🙂
If you have no idea what I am talking about, start here.
After getting the objects converted to AL (using the standard process documented here), I was immediately greeted in VS Code by just over 8000 errors/warnings. Great start.
Luckily half of those were generated by the code analyzers. If you don’t know what they are, see here. Yes, at this point in the project I am considering that half of my issues are “only non-standard and poorly formatted code”. Gotta try and stay positive!
This brings me to my first “recommendation” in this process:
Turn off ALL the code analyzers.
The code analyzers are enabled by default, but can be turned off in your VS Code settings (see here). Once I get to a point where the “non-syntax” errors have been addressed, I will re-enable the analyzers and then deal with that barrel of fun. I’ve done this before in much smaller apps and very quickly got tired of typing ‘()’ 🙂
After disabling the analyzers my list of errors/warnings was brought “all the way down to” just over 4000. Oh wow I’m halfway done!! Ha ha.
The next thing I decided to tackle was another fairly easy one. Dealing with Product Group Code. If you’re not already aware, the Product Group Code feature was deprecated in favour of an improved parent/child Item Category structure. The Product Group Code fields however, were left in the product (not sure I like that, but we can deal with it) and marked for removal (see ObsoleteState property here). This causes any references to those fields to be flagged as warnings. Your code will still build, but this is a heads up that at some point in the future the fields will (probably!?) be removed. As I’m already head deep in things to fix and rework, I decided I’d rather not wait and I will remove references to those fields now.
For me, removing the references to the Product Group Code was pretty easy. We didn’t have major functionality tied to that field, but other ISV solutions may require more effort to remove those references, or, you may just choose to not deal with that now. Up to you.
That’s my update for now, back to fixing more issues. More updates to come!
Happy coding!


  1. Reblogged this on Mark Brummel Blog | Microsoft Dynamics NAV and commented:
    Great start. I fortunately had only 400+ errors on my 1.800 objects. Share your experiences!

  2. Frédéric Vercaemst

    July 30, 2018 at 10:28 am

    Hi Mike, I suppose your database has both custom objects and customized standard NAV objects. When you had imported these objects in a NAV database and created the AL files, you had the customized objects in AL. However, if you then generated the symbol files, these would contain the same objects, and compilation / building your extension would show error to ‘Object Id already exists’. How did work around this error? When deleting the objects from the NAV database, generating symbols would fail, since the references from customized standard NAV objects would no longer be valid.

    • Great question! For the object side of things, I imported only the modified base codeunits and base reports, for the very reason you mention. Since those 2 object types cannot be extended, I left those in the database as modified objects so that they were part of the symbol package. The rest of the objects (ISV objects, and base tables/pages) were moved to the extension, so all object overlapping was avoided. Now, of course when I left those modified objects in the database they referenced a bunch of things that were no longer in the database, but that’s what I’m working through now and I’ll do another update on how that’s going soon.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.