The greatest development platform in the world meets the greatest set of functional libraries, types, methods, and properties as Microsoft Dynamics NAV 2009 R2 allows developers to take advantage of the Microsoft .NET Framework! With NAV 2009 R2, you can reference external .NET components and make use of the Types and Functions from .NET Framework assemblies and from your own or 3rd party code.
Being able to use .NET from C/AL code has been planned for a long time - the whole NAV Server architecture released with NAV 2009 has been building to this time where we can finally reach out from the NAV C/AL context and make use of these functions. The feature is very much part of our roadmap going forward where we want to give developers more power and allow partners to create solutions with much broader reaches than can be achieved within a native C/AL environment.
Referencing an external component will be similar to the pattern that Automation developers are accustomed to - you can quickly choose a component from the variable declaration window and then start using the object in C/AL with full support from NAV's Symbol Menu (F5).
When working with variables of type DotNet, we distinguish between two sorts: Add-ins and those registered from the Global Assembly Cache (GAC). The Add-in type are those that are custom made or custom written, they do not need to be strong-named, and they may also change or are updated often. These components must be copied into a new directory (the Add-ins directory) on the developer's C/SIDE installation in order to be utilized. Variables based on types registered in the GAC are less likely to be swapped around but support strong-named types and include components like the .NET Framework. .NET Framework components have the additional benefit that they are already deployed on computers so there is no need for additional deployment!
Rather than elaborate more on the properties and definitions, let's look at a sample. In this code sample, we will use methods from the .NET Framework to retrieve a list of processes running on the NAV Server and show the process IDs in a message box. The sample is not exactly an ERP task but shows what can now be achieved by using .NET and hopes to show that familiar code patterns can be applied.
This screenshot shows the whole solution:
Notice that we have declared two DotNet variables here - myproclist, which is a System.Array and holds our list of processes, and process, which is a System.Diagnotics.Process subtype. Both variables are from the .NET Framework and are thus registered in the system GAC and we don't need to worry about deploying them for when we run the code.
Notice also that unlike Automation (based on COM), you don't always need to CREATE the objects. In DotNet, objects need to have a constructor called when they are instance-based or they may be used directly if they are static. The GetProcesses method is a static method in .NET, as we can see in the information section in our ever-helpful Symbol Menu.
Notice also that the C/AL code is able to loop through the Array. Using arrays (be they NAV arrays or .NET System.Arrays) is such a common programming pattern that it would be very wrong of us to not include it.
Of course using .NET is only supported on the NAV Server and, like Automation, you can also run the .NET objects either on the NAV Server or on the RoleTailored client.
Using .NET in C/AL will open many new options - more than we can possibly imagine. We hope you'll enjoy using this feature from NAV 2009 R2 and go on to make some fantastic new solutions for all our customers!
Good luck and happy coding!
To view a recorded version of the Hot Topic session about .NET Interoperability, see the Partner Learning Center.
It is really a great feature that you implemented in the R2-Release.
1) What about DOTNET-Application, that fire events ?
2) Can I receive these events in the C/AL-Code ?
3) How can I receive these events in the RTC ?
That sounds great but i don't understand this sentence:
"Of course using .NET is only supported on the NAV Server"
Does that mean it doesn't work on the SQL-Server?
Or does that means that the .NET objects are only available when installed on the Middle Tier server?
I'm completely sure but I think he means that you can only use DotNet objects in Nav-Server based parts like the RTC and webservices. You can't use them in the classic client as that works directly on the sql-server and not through the Nav-Server tier.
Yes this is correct. While one can decide to run the .Net object client side or server side, .Net interoperability can only be used in the 3-tier NAV system, and not in a classic client based system.
And please note that a .Net assembly used with interop - if not in the GAC - at runtime need to be in the Add-ins forlder of the Server or the RTC, depending on whether server side or client side interop is used.
when it will launch this version? I can not wait to try it!
C/AL meets .Net - awesome, love it! :-) What about datatypes? Can you post a table which shows how you map C/AL data types to .Net data types and vice versa. And is there a mapping table for C/AL to SQL datatypes? Thanks.
I have an additional question: The .NET Framework uses Unicode (UTF-16) for its strings, what about NAV? And are there any issues which we have to consider when we are using .Net strings? Thanks in advance.
Thanks for your comments and to the folks who chimed in with replies to the questions. You're completely correct so I won't go over that again.
@Mike, its a good question to ask about datatypes. But rather than answer here, I think I'll work on another blog post and put that up soon (~2 weeks). In general though, we've tried to map our datatypes where they most make sense NAV Integer can be used when .NET wants to have an Int or an Int64. A .NET String can be returned into a NAV Text or into a NAV BigText.
I'm glad to see so many people excited about R2 an I share your desire to get this out on the market ASAP! Fingers crossed that's going to be not too far away!
Hi Stuart, great feature and really nicely "embedded" into the C/SIDE!
Will it be possible to use instance-based methods of .NET assemblies or only static methods will be available?
For example, will it be possible to write something like this:
_myregex := MyRegex.Regex('(?<user>[^@]+)@(?<host>.+)'); //System.Text.RegularExpressions.Regex
_match := _myregex.Match('firstname.lastname@example.org'); //System.Text.RegularExpressions.Match
That is a great news for all the community !
i've got a little question. Is it possible to render .NET controls ? Like using charts c# objects, or render a form or alike?
hosting of .NET controls in pages of the RTC is possible with the indroduction of Client Add-ins. We had already introduced this capability with NAV 2009 SP1.
Here is a blog about this topic:
Yes, i'm aware of the .NET addins, but it must be manually installed on each machine no?
Can't we do the same thing with .NET Interoperability directly in C/AL?
Yes, Client Add-ins must be installed on each client machine. (But take a look at here for on-the-fly auto deployment: blogs.msdn.com/.../auto-deployment-of-client-side-components.aspx)
AL code is server side, so - due to network latency - rather not suitable for interaction heavy code (like mouse hover handling). But with a generic viewer control that gets the rendering information from the server (once in a while), you certainly can get to a more server centric solution, like in any Web Application. A sample would be a 3D interactive viewer for 3D item models, that you feed with models from the server. But you leave handling user interactions for multitouch zooming, tilting, panning, 3D hardware acceleration to a client control.
Hi Again !
Yes i see your answer on mibuso too ! Thank you very much for your advice, i've totally miss the auto deployment ! Thanks again ! :-)
I wrote up a couple of blogposts intended on guiding diehards C/AL devs intending on breaking out of their shell and carefully tiptoeing around .Net interoperability.
Perhaps they can be of some use for people landing on this.