Another NAV TechDays is over, and this one was the best so far. 950 people from all over the world all passionate about NAV and technology and eager to learn and share and discuss the latest in NAV. It was amazing, Luc did a great job again, and I am looking forward to the next year, hoping this conference makes it beyond 1000 attendees.
Continue reading NAV TechDays 2015 wrap up
Microsoft Dynamics NAV 2016 brings many new features, one of which is a set of PowerShell cmdlets to manage add-ins. These are:
While these cmdlets are certainly useful for installation and deployment, I find them even more useful during development. When I blogged about deploying resource files automatically during development some months ago, I showed how you could use PowerShell during build process in Visual Studio to invoke a codeunit that registers control add-ins. Now, in NAV 2016, these tasks are a lot simpler with these new cmdlets.
Continue reading Deploying control add-ins during development in NAV 2016
[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.
Continue reading Sorting out the DLL hell, Part 3: The Code
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.
Continue reading Sorting out the DLL hell, Part 2: The Solution
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.