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 this, append the –Confirm:$false switch to such command. That sets the ConfirmPreference to none for an individual command, and confirms its confirmation dialogs.
Yesterday I posted a quick tip, which quickly got some comments about it being wrong. Since I know people who commented were unlikely to say something incorrect, I went to check on, because I myself experienced difficulties that made me write that post.
So, I analyzed to see who’s right and who’s wrong, or better yet – to see why different people might get different results.
Here’s the results.
(Update, 20.4.2015: As it turns out – this post is not entirely accurate, as pointed out by Johannes Sebastian. Please read the next post to learn more about which parts are, and which aren’t correct.)
Control Add-ins written in C# are not cross-version compatible. You cannot use an assembly compiled for 2013 R2 with 2015 (or the opposite way around, or any other version combination for that matter) without recompiling it with correct extensibility framework assembly reference.
Control Add-ins written in JavaScript don’t have to be recompiled, are mostly interchangeable, and are (so far) guaranteed to be forward compatible. You can always use a version built for 2013 R2 in 2015. You can use a version built for 2015 in 2013 R2, but the opposite way around is only true if you don’t use any of the new JavaScript extensibility features not supported in earlier versions.
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.