A few days ago I have published my PowerShell script that streamlines and automates deployment of control add-ins from Visual Studio. Over the past couple of days I have improved it a little bit, and fixed a few bugs, so here’s an updated version that is more resilient to your project structure, produces resource zips that NST not only extracts, but actually understands, and does a little more.
Ancient wisdom goes that you cannot have more than one write transaction going on at the same time in a single session in NAV.
This is absolutely true, in and out.
Some features, like Activity Log, will leave you wanting to be able to write to the database outside of the normally running transaction.
Wouldn’t it just be beautiful if you could:
- Write to the database, and then persist the change to the database even if an error happens during the transaction? (without cough! TryFunction, cough! cough!);
- Not cause any locks to remain at the target table for any longer than it takes to do the write itself, without having to call COMMIT on your “regular” transaction; and
- Not use temporary tables, because a system error (however unlikely) could cause the data to not be persisted if crash happens before temporary table is flushed to the physical one.
Well, in fact, you can do this.
[Update, February 8, 2016: there is a new version of code from this post. Please check http://vjeko.com/dynamically-loading-assemblies-at-runtime]
Okay here we go. In this post I deliver the promised code that handles automatic deployment of all your assemblies to client and server, as needed.
For any of you who haven’t read the last two posts, I am talking about automatically deploying .NET assemblies to clients and server, from the database, on demand, at runtime.
This will be heavy on code, so fasten your seatbelt and brace for impact.
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.
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.