DotNet

A lot of us still have a ton of C/AL code sitting around in existing databases that sooner or later will have to be moved into AL. A lot of us also have a ton of AL code using DotNet that we want to be able to run in Microsoft’s cloud (that is: not on-prem).

I said a word or two about progress last week. Apparently, VS Code is not the only place where we take a small step back to be able to make a huge leap forward; .NET might seem like another one. You know it, right?

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.

And yes, I almost forgot… Somebody (sorry, I didn’t catch the name) asked me to put my life hack on the blog as well, so here it is. For all of you who were not there, I use this as a template for declaring .NET variables – until Microsoft provides means to declare them in a simpler ways. Inline, anyone?

Thanks to everybody who attended my session today at NAV TechDays 2014 in Antwerp. As promised, here are the goodies from the session. I’ve simply taken the objects and I deliver them here with no explanations or comments – when Luc publishes the sessions and the slide decks on Mibuso, you’ll be able to figure out what’s what.

So, NAV TechDays 2014 have started, again, with the pre-conference sessions that were all sold out and packed full. Today I had an extraordinary pleasure to teach the advanced .NET Interoperability concepts to 15 people that came from all over the world, from Brazil to Australia.

You may love C/AL as a language, but there is an area in it that you must just hate. It’s the error handling. Plainly put, and being actually quite positive about it, in NAV, error handling just sucks. If an error happens, it happens.

Most of What’s New information about NAV 2015 will mostly talk about the Word report layouts, as well as the C/AL support for these. However, most of the What’s New documentation doesn’t have a single word about what I find among the most exciting new reporting features in C/AL: the capability to programmatically control the request pages.

A friend asked my by e-mail today about a problem he encountered with DotNet interop: how to access a property of an object, if the property name matches a reserved word in NAV. A simplest example is from the Microsoft.Dynamics.Nav.SMTP.SmtpMessage class that comes bundled with NAV 2013.

When I was writing my last post I had a distinct feeling that I was trampling over some boundaries of good NAV design. After all, you should not do stuff like that, NAV isn’t meant to do things like that, or at least that was how I felt. And then two things happened. First, I asked myself: what the heck, why not?