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#.
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#?
Marije Brummel Blog | Business Central, Azure and more... 
Great topic and very interesting to think about. Looking very much forward to read more.
LikeLike
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
LikeLiked by 1 person
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.
LikeLike
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.
LikeLike
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.
LikeLiked by 1 person
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.
LikeLike
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” 🙂
LikeLike
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?
LikeLike
Reblogged this on Khotso Charles and commented:
Good read
LikeLike
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
LikeLike