Dynamics NAV is moving to C#, get ready to follow!


Ok, maybe the title is not to nice, but hey, I got your attention.

Since the introduction of the Three tier environment, Dynamics NAV runs on C#. In the first versions it was hidden and closed, but with the intoduction of DotNet interoperability it is possible to move bigger pieces of business logic from C/AL to C#.

c-sharp-logo

On top of that, the world is asking, no demanding, more integration between applications. Webservices are the standard of doing that. When consuming webservices in Dynamics NAV, you end up writing C# code very fast.

In the last six months or so I spend a large amount of my time writing C# code. This started with interfacing and consuming webservices. But getting the hang of this thing, I started doing more with C#. The possibilities are endless.

I wanted to spend some blog articles on my journey exploring C# as a C/AL developer. There are some fundamentals you should understand which will make life a lot easier. Plan is to start these entries end of summer and contintue during fall.

So DotNet interop allows you to start using C# for business logic, but one of the questions is should you. C/AL is more or less open source and C# will get compiled, debugging is harder and so is managing your code.

Part of the examples I plan to write are not even using C#, you can do a lot of cool stuff just using standard DotNet libraries which means you do not leave C/AL.

Should NAV move to C#

This is an ever returning question and to answer it, you must understand C# and C/AL. C/AL programming is based on binary objects which get converted to text if you open the code whilst C# is text based programming.

Dynamics NAV has 1000ds of C/AL objects which are manageable because we have object designer and object numbering, Visual Studio works with projects and files. Imagine NAV as a project and browsing 1000nds of .cs files in the Visual Studio project window. Even if Visual Studio could understand C/AL we would need a smart way to browse through objects.

Visual Studio is also not used to multiple programmers working on the same “objects” eg. database. If you use Visual Studio online you can make local copies of projects which are later merged together, automatically if possible.

Then there are the typical NAV commands of which talking at the database is the biggest challenge. For most developers it will not be a big issue to move to C# syntax with its {} structures, this is easy to get used to. A bigger challenge would be to make C# aware of SETRANGE and FINDSET. It does not know these commands. You would need function libraries that understand this syntax.

But!

What if it did? What if you could write C/AL commands like SETRANGE and FINDSET in C# and then use all the possibilities C# has and C/AL does not have, would that be great? Or would that take away “simplicity”?

React! Leave you opinion!

During the next months I will be going through what I learned in C# and I am still learning. The journey is so extremely cool, C# has so many great features that will let your creativity go bananas.

What do you think?

Are you ready to move to C#?

Ready to Move Cardboard Box Moving Relocation

Advertisements
This entry was posted in C#. Bookmark the permalink.

14 Responses to Dynamics NAV is moving to C#, get ready to follow!

  1. Great topic and very interesting to think about. Looking very much forward to read more.

    Like

  2. I’ve been waiting for C# to arrive in Nav ever since it was vaguely announced for the first time, probably 8 years ago… :-O

    Liked by 1 person

  3. Peter Tijsma says:

    Since NAV moved to 3-tier, I’ve been waiting on a C/AL plugin for Visual Studio. This way we as C/AL developers could gradually move over to Visual Studio and C# while making use of all the nice goodies that VS has to offer (like IntelliSense).
    By now I’m even more convinced that the only way to go is Visual Studio and C# because I think I’m currently developing more time in Visual Studio then I’m in C/AL. It’s not even only C# I’m developing in, it’s also building add-ins using JavaScript, JQuery, Css, etc. etc. so more and more languages are surfacing and all are integrated in Visual Studio.
    Adding C/AL as a additional language to Visual Studio would – to my believe – be a huge benefit for the Dinosaur C/AL developer to get used to the new development environment and at the same time get the taste of using all the other languages (like C#).

    In time it’s just a matter of announcing C/AL will be discontinued and remove it from Visual Studio, but then the NAV Developers will be used to C# already.

    These days I’m a huge fan of C# and its limitless powers (many thanks to Vjekoslav Babic for this 😉 ). It has SO much more to offer and as said, the possibilities are simply limitless.

    Like

  4. Anders Hedegaard says:

    Simplicity is beautiful and certainly not limitless. I believe the platform is the problem and not C/AL. I think the silent majority of NAV developers does not want Visual Studio or C#. Their focus is on processes and business solutions and not technology. Keeping it simple and stable is important to be efficient. For me the solution to merging code from multiple sources, integrating to web services and being able to test this fast and efficiently should be part of the functionality provided by platform developers and not the application developers. Coding the application can just as well be C#, the language does not matter. However, the tools to merge functionality, integrate services, write reports, debug and test must be simpler than what is offered by visual studio, reporting services, scripting, text files, source control and limitless possibilities.

    Like

  5. Pingback: Dynamics NAV is moving to C#, get ready to follow! | Pardaan.com

  6. devch says:

    I believe the best integration would be to use visual studio but keep C/AL as the language for the business logic. There is nothing realy wrong about the language its perfect for what it’s used to in 99% of the time, and that is data access. But the both worlds need to come closer together! And i think development should definitly move to visual studio because it’s THE IDE. The current dev. environemnt is just a huge joke to be honest… its so outdated! If you ever worked with Visual Studio + Resharper you think get nuts using the dev environment.
    Plus there needs to be native integration of TFS for nav. It’s nice to have all these little posts and tricks about using tfs with nav in some way (more and more people are blogging about it) but to be honest none of these are realy integrated because the dev envornment needs to change to truly integrate with that!
    I realy hope these things will come in the future.

    Liked by 1 person

  7. I agree. We need Visual Studio for TFS integration and for “Find All References”. But C/AL is fine, we just need better .NET interoperability, e.g. invoking members of members in one statement.

    Like

  8. I don’t think that the functionality of VS will increased in the next years so much, that it will be able to handle the NAV Table objects.
    And for “Find All References” we have the “Objectmanager Advanced” 🙂

    Like

  9. Pingback: Implementation Pattern #1 | Classes, Methods and Properies | Brummel Dynamics Services B.V.

  10. Pingback: Should the Dynamics NAV object designer be replaced by Visual Studio and C#? - Erik P. Ernst on Microsoft Dynamics and Navision - Dynamics User Group

  11. Attila M. says:

    Thinking in OOP manner, the object browsing it’s the same as you browsing the .net assemblies in visual studio. So what’s the problem?

    Like

  12. eddiesel357 says:

    Reblogged this on Khotso Charles and commented:
    Good read

    Like

  13. This is what I would call the DSL (Domain Specific Language) vs GPL (General Purpose Language) dilemna.

    Sure C# is an amazing and powerfull GPL, it supports OOP, super flexible and the only limits to what it can do is your creativity and your programming skills. But it’s a double edged sword!

    While C/AL is a DSL, it’s an old dog, it seems ugly at first sight, however you get major benefits you will never get with C# : Productivity for both code writing and debugging.
    For me the super-limitation of what C/AL can achieve is it’s power.

    Let’s imagine for a second that the entire NAV code base was written in C#,
    and a sharp C# programmer implemented a customization doing complex array compression/parsing using Covariance and Contravariance (in C# Generics!)

    Then an “average” C# developer is asked to make change to this customization,
    and he never used contravariance in his life. (he did not even knew that such a concept existed in C#)
    sure he can google it and get help on this : http://blogs.msdn.com/b/csharpfaq/archive/2010/02/16/covariance-and-contravariance-faq.aspx

    But my point is that it’s not like C/AL where even your GrandMa could read/alter/debug the code 😉

    C# is like an ocean with no shore, where a smart ass could implement a feature using a dusty corner of .NET that the mere mortal never seen before.

    Sometimes in NAV project you have no other choices than using C# (ie: interfaces, displaying complex Data Visualization tool on the front end) and it’s fine.

    But for the most part cutting major piece of code under the constraint of C/AL has got it’s benefits in the long term in the NAV realm, at least 99,9% of consultant shall be able to read your code.

    But I might be wrong., let’s wait & see …

    // Tarek

    Like

  14. Markus says:

    Imagine that the Dynamics NAV codebase was written in C# with an actual API for extending or overwriting standard functionality. Wouldn’t that be nice? I hate digging through 1.5k LOC Run triggers in Codeunit 80 and 90 just to make a simple extension, never knowing exactly what happens because it is a huge mutable mess of an oversized state machine that is trying to run the whole world in one function. I would much rather write an extension that plugs into the standard instead messing with it directly.
    If you have ever used LINQ you curse the C/AL ways of manipulating data. Having filters and loops get you pretty far but it does not scale with more complex tasks and large data sets. The C/AL logic code gets complicated very quickly which means that you have to go over the wire more often because Dynamics NAV is unable to express the programmers intent directly to the DBMS. The famous Einstein quote holds true: “Everything should be made as simple as possible, but no simpler.”
    I do not agree with you on covariance and contravariance. Of course, if you implement a feature you need to know what you are doing. However you do not have to be an expert to simply use covariance and contravariance because they work as one would expect. Treating an array of apples as an array of fruits? No problem there. You do not have to write covariant and contravariant types yourself if you feel uncomfortable. It is optional.
    My bottom line is that I’d rather have a powerful tool and only use a subset of its capabilities than having a simple tool that does not scale.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s