Deploying .NET assemblies to clients and servers in need is no simple affair. In my last post I have explained the problem, and announced the solution.
As promised, in this post I bring you the solution.
To be fully honest, this post only brings the conceptual solution, just a little brain game for you to train your .NET brain muscles a bit. The actual code I’ll deliver in the next post.
Not that I am saying it’s a good thing, but trial and error is a fairly common approach to debugging in the NAV world. We’ve all done it. Heck, even with the comprehensive testability framework built in, we all still do it more often than we’re happy to admit while sober.
But the overlord of trial and error in NAV is development of control add-ins in JavaScript. JavaScript itself is making it difficult in the first place, and then integration with NAV makes it even harder.
There is one situation in particular that’s adding a cherry on top of all of problems, and it’s the creepy “A script error has occurred” error message. It’s the equivalent of the BSoD.
Some NAV PowerShell cmdlets (such as Import-NAVApplicationObject) don’t have the -Force switch, and always ask for confirmation regardless of whether you include the -Confirm switch or not. To work around…
Switching from C# to JavaScript to develop your control add-ins might get you scratching your head more often that your scalp, or nails for that matter, might be happy with.
One of those is overloading. In C#, this is a no-brainer:
However, when you want to do that in JavaScript, if you are not a JavaScript developer, making this work is not as straightforward as a regular JavaScript Joe would find it.
When you reference a .NET class that exposes events, and you switch on the WithEvents property, C/SIDE creates the event triggers for you. If you later want to update the reference to the .NET class, for whatever reason (like, there is a newer version of the assembly), updating the reference will actually delete the event triggers with all the code in them.
To be fair to this non-feature, at least it warns you politely:
This is not something you experience once in a geologic era. When you are developing your own assemblies, this will happen fairly often – as often as you add or remove events to/from your classes, and you want to reflect that in the Development Environment. Or as often as you increase the version of your assembly.
Unfortunately, there is no way in the Development Environment to update the reference while actually retaining the event triggers or code in them.
But still, there is a way, and a fairly easy way at that.