Are there plans for NAV dev to move to .NET and VS?

Charleh

Forgive me if this has been asked before or if the info is out there somewhere, but I'm having a hard time finding it.

I'm a long time .NET developer and I've been working with NAV for a while now - since implementing 2013 at several clients, I'm wondering what Microsoft's plans are for the development environment and the classic NAV code that most NAV devs are familiar with. Are MS moving the whole lot to .NET and MS tech (the same way they have done with the back end, middle tier and now the end user client)?

We have a graduate at my place of work, and the company are looking to train him and move him into the NAV world of dev/consultancy and I'm wondering whether it would be worth him getting a handle on .NET tech. Obviously having a foundation level of knowledge would help as the new stuff is written on top of WPF/WCF and all that goodness, but does he need to look into learning the .NET framework or are we always going to have classic C/AL?

ppavuk

I hope that this never happens I believe most of NAV developers love c/side and don't want it to be replaced with VS But, who knows what MS guys will do though ...

generic

You mean this?

Alex_Chow

Some Microsoft dev executive told me C/Side is not going away. We'll see how long that last.

Rob_Hansen

A few years back the consensus was that it would all move to .net...then the partner backlash had Microsoft backtrack and reaffirm their commitment to C/AL. The amount of retraining and redevelopment (of ISV product code) was a significant concern for partners. I'm glad this decision was made. I've seen some great NAV developers over the years that weren't hard-core technical types...and I've seen some terrible NAV developers that WERE hard-core technical types. Keeping NAV's code base on a simplified/rapid development platform has many, many benefits. Of course, the .net developers can pull more off with add-ins and extensions, so it's a good balance of the two worlds currently.

generic

MS can keep CAL. just move the IDE to Visual Studio.
We are already using Visual Studio for Development (Reporting). And as you mentioned add-ins.

They can improve CAL by allowing us to use LINQ or anything else that will improve our RAD development.
The way I see it right now, since the debugger is in RTC, we will be using it for dev as well

deV.ch

@generic
I totally agree with you! This is the way to go, VS has to come, CC/Dev Env. has to go. But C/AL has to stay. I don't think writing business logic in c# would make sense, you always need the right language for the task, and c# is not the right one. Some sort of switching would be nice, if we could write c# code directly and expose these methods to the C/AL (without writing assemblies that must be deployed etc, i mean directly integrated and exported to the fob (if they stay...).
But most of all we need a proper IDE which VS can provide us. Well we need it anyway for reporting, addins, assemblies.
So killing the classic client would make sense, so we can stop from hopping around between CC, VS and RTC...

ppavuk

That would be nice to utilize VS as development tool, but something inside me tell me that unlikely MS will do. VS is a great tool, but thing is that MS need to sell it more, and to attract new developers to their stuff. Unlikely C/AL is something that can improve sales of VS and attract a new developers, so most likely MS will not invest into integrating C/AL to VS. I think they more focused on windows 8 and windows phone 8 now in terms of future VS development...