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.
Let me tell you right away if you need to read this post at all. If you never wrote a single .NET class library intended to be used as a .NET interoperability assembly from C/AL, or if you never ever deployed a .dll file into the Add-ins folder of either Service or RoleTailored Client, then you probably don’t want to read this post.
Good, since you are still reading it means that you either deployed your own or somebody else’s .NET stuff into NAV’s client or server’s Add-ins folders. If you ever did so, you probably did not enjoy the experience too much. If you did enjoy the experience, maybe you should not read any further either.
Even better! Since you are still here it means that you didn’t enjoy deploying assemblies. Let me break some good news – all your problems are now gone! And I am not talking NAV 2016, I am talking NAV 2013 and anything newer.
In my two last posts, I laid out the technical design of the Preview Posting feature, and then showed how to simplify its design to get around the unwanted behavior of TryFunction.
One thing is obvious from these posts: Preview Posting wants to simulate posting of a document (or journal) to show what the results would be, but without leaving any actual trace in the database. In database lingo – we want the transaction to be rolled back.
Rolling back is no brainer. Simply throw an error, or do a silent abort, Except if there is COMMIT. In that case, no rolling back helps.
I have announced earlier that my today’s post will be about how to nest transactions in C/AL so that an inner COMMIT has no effect on the transaction as a whole, which can still be successfully rolled back.
That’s what this post is about.
In my yesterday’s article about the Preview Posting feature in Microsoft Dynamics NAV 2016 I said there are at least two ways to redesign it to avoid both the unnecessary complication and inherent dangers of the TryFunction feature behavior.
In my first post, I’ll show that it would have been perfectly possible to achieve exactly the same functionality without try functions. And it would take a total of one new line of code, one changed line of code, and six removed lines of code.
Let’s go and simplify it.
One of great new functional features of Microsoft Dynamics NAV 2016 is preview posting. It allows you to preview all the entries that would result from posting a document or a general journal.
Preview posting is not a simple thing. If it was, Microsoft would have delivered it years ago. There must be something in particular with NAV 2016 that powers preview posting, so I decided to investigate it and see exactly how it works.
I am not particularly happy with what I found out, but I have also learned some valuable lessons from it. In this post, I’ll share my findings.
We all use records. And we all used to whine about records not supporting all the features we need. And they still don’t, but in Microsoft Dynamics NAV they support much more.
Some of the new features are well documented, some are somewhat documented. So here’s what I figured out so far is new about the Record data type.
Well, control add-ins are not new in NAV 2016, they have been around for a long time now. But, they have been improved and this blog post is about these improvements.
Of course, the improvements are exclusively in the Web client framework, not the Windows client, and I am educated-guessing here that we won’t really see many improvements in the control add-in framework for Windows in the future. Why would we? All control add-ins should target all clients and use the Web framework, anyway so the case for Windows client is getting weaker and weaker.
If this was a joke, then it would be one of those good-news-bad-news jokes. So which one do you want first? To stay true to all jokes of this kind, I’ll start with good news first.
Good news is, you now have TryFunctions, that return true if no error happens, and false if an error happens inside them.
And the bad news? You’ll never want to use them.
The best news sometimes go silent, and the newest release of Microsoft Dynamics NAV has just proven this claim.
Ladies and gentlemen, Microsoft Dynamics NAV 2016 comes shipped with full set of application test toolkit, that you can use to test your customizations against regression issues. Even though most partners out there have never even tried the testability features, let alone written a unit test (for all the wrong reasons), testability framework of NAV is one of its strongest points, and was the last missing piece to complete the big puzzle called Road to Repeatability.
When comparing .NET variables, including Enums, you cannot use C/AL comparison operators. To compare .NET variables, you must use the Equals method (of the System.Object type) that all .NET types implement or inherit. So, instead of IF var1 = var2, or IF var1 = var1.EnumValue (in case of an Enum), just write IF var1.Equals(var2), or IF var1.Equals(var1.EnumValue).
I see this mistake often being made or attempted by developers, even though it has been documented inside .NET Interoperability documentation since it was introduced with 2009 R2.