Since the days of Visual Basic 6, where we were creating OCX (Custom Controls) for Navision, and up till now with COM Interop with .NET programming language, the .NET platform has become a great development platform. But because of the limitations of interoperability in NAV we haven’t been able to use true .NET assemblies directly within NAV.
Until now! R2 as you know has announced its arrival in next month (hopefully), and with it the introduction of .NET interop.
The Microsoft Dynamics NAV Team Blog has a great post on this subject, as well as real examples of how to use it. Check it out, this will rock your world!
I would recommend you see/take/watch this hot topic on Partner Learning Center: Microsoft Dynamics NAV 2009 R2 Hot Topic: DotNet Interoperability. For more great .NET information i would suggest you visit a site like http://codeproject.com. Here is a quick excerpt from the blog post on NAV Team blog:
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!
