Dynamics Nav 5.0 Preview Presentation TechEd

Waldo · 2006-07-03

C# is managed code now, but will it remain "managed" in the future?

bbrown · 2006-07-03

It is not uncommon for Microsoft to imbed features in their products that are not intended (or supported) for use in production systems.

Waldo · 2006-07-03

You're supposed to make a choice of architecture per implementation. Depending on your choice, you design the new Dynamics forms, or you design the Navision forms. How we are supposed to develop the service tier (i.e. how is that part visualized) I don't understand.

This is what they've told me: you don't "develop" or "design" the service tier. It is there when you're done developing in C/SIDE. When compiling, your service tier (assemblies) is ready to be published (and probably automatically published) to IIS. With the Dyn. clients you connect to IIS and you're able to work.

Marije_Brummel · 2006-07-03

Yep, I can confirm that.

DenSter · 2006-07-03

I know all that, but those are general terms. I just want to see the details behind the curtain you know

Phenno · 2006-07-03

DenSter wrote:

I know all that, but those are general terms. I just want to see the details behind the curtain you know

phuhh... that means, no quicky repairs at customers place (like on-fly report requests that could be solved on the place)... and, that means big development "workspace" in developers place.

afaik, i read somewhare that, althought C# is managable, all business logic is intended to be developed in C/SIDE. Why do I need C# than (except for the external integration features?)

still, I don't see how can they disallow native clients to access DBs...

Waldo · 2006-07-03

phuhh... that means, no quicky repairs at customers place (like on-fly report requests that could be solved on the place)...

why not?

afaik, i read somewhare that, althought C# is managable, all business logic is intended to be developed in C/SIDE. Why do I need C# than (except for the external integration features?)

I think you have to see further ... Nav6.0 ? You think C# is still managed then? You don't think we'll all be writing C#? If you ask my opinion, I think we're moving to a C# development environment on SQL Server database ... and N5 is just a way to get there ...

DenSter · 2006-07-03

"managed code" simply means that the code is stored as .NET MSIL assemblies, as opposed to COM+ components for instance. C# is one language that can be used to write managed code.

As long as the .NET framework is alive, there will be managed code, it is just a definition of where the components live.

I am not convinced that we will be developing Dynamics in C# directly. One of the things that is so powerful about NAV is the ease of development, the way that it is relatively easy to be a hybrid between a consultant and a development, and they will have to provide a way to keep it that easy. There are some movements toward more 'user-friendly' programming structures (LINQ for instance), but I don't know if that will be simple enough to keep NAV's ease of development.

DenSter · 2006-07-03

Phenno wrote:

phuhh... that means, no quicky repairs at customers place (like on-fly report requests that could be solved on the place)... and, that means big development "workspace" in developers place.

Sure it will still be possible, it's just different technology. We used to have wood burning stoves, then there were microwave ovens. The result was the same: hot food, it is only more user friendly.

It may seem a lot more complicated, but for sure it will not be too difficult to understand once we have it in our hands.

jesam · 2006-07-03

Quote:
afaik, i read somewhare that, althought C# is managable, all business logic is intended to be developed in C/SIDE. Why do I need C# than (except for the external integration features?)

I think you have to see further ... Nav6.0 ? You think C# is still managed then? You don't think we'll all be writing C#? If you ask my opinion, I think we're moving to a C# development environment on SQL Server database ... and N5 is just a way to get there ...

The fact that C# is 'managed' only means that it runs on the CLR and thus runs in a sandbox, has garbage collection and can use all of the base classes in the .NET framework. I can't see any reason why they would make an unmanaged version of C# (how would you do yourmemory managment for instance ?).
Bu I do think Waldo ha it right, we are going to 3-tier .NET development on SQL server. I think with they only kept C/SIDE around to make the transition a smaller leap. For NAV 5.0 they'll only change the architecture, so when by NAV 6.0 everybody is accustumed to the new architecture, they can change the develoment environment to Visual Studio so that you can choose the development language you want (C#, VB.NET, and maybe also C/SIDE). At that point, the ERP system consists of a presentation tier which is built in managed code, a framework of Dynamics classes, a modern IDE and a relational DB under al of that. That would also mean that if I am developing some corporate application, I could use Dynamics Objects straight in my code. Let's say I'm implementing a project for Quality Control and I have all these technical info that at this point is in another DB. If I needed to know some sales info about the Item I could just instantiate the class DynamicsItem and from there on find how good that particular Item sels, and represent that info in my own screens. The goal is that at some point in time we'll talk about Dynamics Object and instances with encapsulated Business Logic, callable from everywhere in .NET, instead of Navision records, tables and codeunits.

Just my idea about all of this.

Waldo · 2006-07-03

DenSter: Sure it will still be possible, it's just different technology. We used to have wood burning stoves, then there were microwave ovens. The result was the same: hot food, it is only more user friendly.

Nice! 8)

DenSter: It may seem a lot more complicated, but for sure it will not be too difficult to understand once we have it in our hands.

I agree. From what I've heard and seen, i'm convinced of this as well.

jesam: Bu I do think Waldo ha it right, we are going to 3-tier .NET development on SQL server...

I'm glad you agree ... but these are just my thoughts, it hasn't been confirmed whatsoever ... .

Don't shoot me if I'm wrong

Phenno · 2006-07-03

well, for me, C/SIDE is very powerfull tool for (more) easy(ier) understanding and applying business needs of customers. I do not say that C# would be a big problem, rather that it needs real programmer/developer and to be honest, lot of features you can do now without some straight coder person...
but that was expected from MS, everything is moving to integration and to an easy extensible form. finally, C/SIDE is not MS product.

but, like Waldo said, that's just my opinion.

Waldo · 2006-07-03

And many others will share your opinion.

For instance older programmers, who haven't been introduced to OO coding ... and never had to, because C/SIDE is not Object Oriënted in any way. All of a sudden they have to (1) learn an entire new language and (2) learn how to code in it in an entire new way (OO).

Me, on the other hand, I'm really looking forward to it, in case it's happening.

Miklos_Hollender · 2006-07-03

Jesam,

I don't think C/AL truly gets compiled to a C# in a keyword by keyword way.
First, the "real" Navision program code is not C/AL but rather the text representation of C/SIDE objects as exported in a text, which contain C/AL code and a lot of other data as well. They have some bytecode compiler that compiles text objects into a kind of bytecode (the fob's) and they already have a nice bytecode interpreter in C++, it's fin.exe/finsql.exe, so I think what they really did is

- rewrote the interpreter in managed C++ which is not a very big task, or maybe rewrote it in C#
- and in the C# assemblies I think they simply wrap together the bytecode as data and the interpreter. Simply because that makes a lot more sense. I have a bet that if you delete all objects from NAV the assemblies will still not become zero size because what's left is the bytecode interpreter.

Therefore I think C/SIDE is here to stay. Truly moving the business logic out from C/SIDE would mean a huge work, and break all those add-ons that are the real key selling point of NAV.

That would also mean that if I am developing some corporate application, I could use Dynamics Objects straight in my code. Let's say I'm implementing a project for Quality Control and I have all these technical info that at this point is in another DB. If I needed to know some sales info about the Item I could just instantiate the class DynamicsItem and from there on find how good that particular Item sels, and represent that info in my own screens.

.NET/CLR was created as a common platform for applications to talk each other that are built in different programming languages. However, this idea is somewhat outdated, because todays trend is SOA, Service Oriented Architecture, which means you can have your applications written on any platform, on any OS, and deployed at anywhere in the world, as long as the interfaces are well defined, with SOAP/WSDL/whatever, which basically means f.e. a method expects two integers as parameters and returns a decimal as a parameter. It would be an outdated approach to directly instantiate a .NET class of Item from an assembly, because it would mean your application must be installed at the same server, also running in .NET and so on. And these are unnecessary limitations. What will instead happen is that my Ruby program running at a Linux server in Budapest can ask your Navision server running on a Windows platform at Deinze about the current Inventory or whatever of an item by sending in a well-defined XML to the web service and receiving another well-defined XML in response and place an order if the Inventory is high enough. This is a lot more powerful approach. There will simply be no reason to instantiate NAV class directly unless you need something with an exceptionally high performance (but in that case I'd rather read the database directly). This is the concept of SOA.

The concept of many languages running on .NET is getting to become deprecated a bit - VB.NET for beginners and C# for everybody else and stuff like J#, Jscript.NET are getting less and less attention. The reason is simple: if you want to use .NET because you want to use .NET libraries then simply no reason to not use C# as learning the syntax of a programming language is maybe 3 days while learning the libraries is about 3 months so you don't save much if you use your old language on .NET like Jscript.NET. And actually as most examples and tutorials on the web are C# and VB.net, so you even lose many useful sources of learning aid. In the other cases, when you don't need or want to use .NET libraries, but you would use .NET only because you want to talk to a .NET application, then there is simply no reason to write your app in .NET - you can write in anything from Ruby to PHP or LISP without any .NET/CRL support: as long as both sides are service-oriented (expose their functions/methods in SOAP/WSDL web services) they can easily talk to each other.

Phenno · 2006-07-03

Waldo wrote:

And many others will share your opinion.

For instance older programmers, who haven't been introduced to OO coding ... and never had to, because C/SIDE is not Object Oriënted in any way. All of a sudden they have to (1) learn an entire new language and (2) learn how to code in it in an entire new way (OO).

Me, on the other hand, I'm really looking forward to it, in case it's happening.

I'm not afraid of learning new concepts or languages, after all I'm familiar with OO concept.
It's just that C/SIDE was closer to business logic it self. XML (f.e.) is powerfull tool but for everything, C/SIDE is like a tool for business logic almost on some meta-level.

Miklos_Hollender · 2006-07-03

Waldo,

I think nobody has to fear of OO. Advanced OO concepts simply don't apply to database-oriented business logic, where classes are mapped to tables and attributes to fields.

For example, Ruby is one of the most advanced OO languages in the world, it allows so high levels of metaclass black magic that surely blows the hat off everybody who grew up on Java. Still, in the primary business logic framework for Ruby, which is Ruby on Rails, you can create a new customer with the following code:

cust = Customer.new
cust.id=12
cust.name ="Joe"
cust.save

Does it need any explanation to anybody who ever saw a record variable in Navison? I think not.

Encapsulation (like in the above example) is already there in record variables. Inheritance and polymorphism... I think it can only apply to a very basic level. Maybe classes that represent tables inherit from a common ancestor but that's all. Advanced concepts like singletons, factory objects etc... forget that for database-oriented business logic, they simply do not apply to that field.

Waldo · 2006-07-03

I hope you're right. 8)

ara3n · 2006-07-03

Waldo wrote:

phuhh... that means, no quicky repairs at customers place (like on-fly report requests that could be solved on the place)...

why not?

Create Assembly – a DLL is created based on the objects in the database.
All objects will be compiled at the same time.
No granular compile (as in Dynamics NAV 4.0).

So when you make a new report. You have recomiple all the object to create a DLL that will be uploaded on IIS. It takes an 10- 20 min to compile, depending on the objects. I'm sure 5 will have new set of objects. You probably have to reboot IIS and everybody will loose connection.

Miklos_Hollender · 2006-07-03

If in NAV6 or later the business logic truly moves into C#, then the problem will not be the OO, but the fact that business logic running outside from an application needs a lot more boilerplate code than one that's interpreted inside.

Consider the following C# code which is a duplicate customer (Account in MSCRM terms) name detection service for MSCRM, right from the MSCRM 3.0 SDK:

	protected override void Render(HtmlTextWriter writer) 
    {
		Response.Clear();
		Response.ContentType = "text/xml";
		
		// Load the requested "name" from the querystring
		string newAccountName = Request.QueryString["name"];
		
		// Make sure the requested "name" appears valid
		if (newAccountName != null &&
			newAccountName.Length > 0 &&
			newAccountName.Length <= 100)
		{
			CrmService service = new CrmService();
			service.Credentials = System.Net.CredentialCache.DefaultCredentials;

			QueryByAttribute attributeQuery = new QueryByAttribute();

			attributeQuery.Attributes = new string [] {"name"};
			attributeQuery.Values = new string [] {newAccountName};
			attributeQuery.EntityName = EntityName.account.ToString();

			RetrieveMultipleRequest retrieve = new RetrieveMultipleRequest();
			retrieve.Query = attributeQuery;

			RetrieveMultipleResponse retrieved = (RetrieveMultipleResponse)service.Execute(retrieve);

			// Render the response to the caller
			if (retrieved.BusinessEntityCollection.BusinessEntities.Length > 0)
			{
				Response.Write("<duplicatesFound>true</duplicatesFound>");
			}
			else
			{
				Response.Write("<duplicatesFound>false</duplicatesFound>");
			}
		}
		else
		{
			Response.Write("<error>The Account name requested is invalid!</error>");
		}
    }

The reason this code is much longer that it's C/AL counterpart would be is

1) it's an external application, an independent web service that queries the MSCRM database from the outside. Therefore it needs the boilerplate code of parsing a request and replying in XML. Also, it has to authenticate itself to the MSCRM server.

2) It's simply implemented stupidly in MSCRM. As you see, they use different Query objects that return generic BusinessEntitites instead of simply asking the business objects directly to filter themselves and return a collection of instances like in C/AL. But it does not HAS to be this way. It was simply a wrong decision, but there is nothing in OO that would make it impossible to implement SETRANGE, FIND etc. as methods.

For example in Ruby on Rails this duplicate detection would be something like (besides the error handling

if Account.find_all("name = ?", params[name]).length>0 then
   render_text "<duplicatesFound>true</duplicatesFound>"
else
   render_text "<duplicatesFound>false</duplicatesFound>"
end

Stuff like that are not inherently impossible in C#. Sure, MSCRM developers surely did not know how to develop a proper API for business logic but I think the NAV teams knows it and there is nothing inherent in OO or C# that would forbid it.

kine · 2006-07-03

Uff... it tooks some time to go through this thread... :-)

There is my opinion: C/AL code will be possible to use in next versions, because it is not hard to create "translator" between C/AL and C#. After that, you can generate C# code for any C/AL trigger. And what else you need? Just visual side of the application - and as you can see in the presentation - the visual side of the app will be created through XML describing the data you want to present. The used client (Dynamics client or something else...) will present these data to user. It is why there will be new properties on each field in the databse (more metadata for each field).

Back to the report designer. In the presentation is the process - export into RDL, design it, import it back. It means - you are doing it manually. After your changes are done, you will create the c# package which you will publish to the IIS.

C/SIDE vs. Dynamics 3-tier client : You will be able to use BOTH clients in one Environment (there is big OR, not XOR)! It means - you can start some Customer on C/SIDE and shift him step by step to new Dynamics Client as you will create the new Forms and Reports for this new client. For example, all users will be using C/Side client just management will be using the Dynamics Client to see their graphs and KPI, after some time, you will prepare new "Pages" for Warehouse etc... After some time, when your company prepare whole your solution for the new Dynamics Client, the customer will be using this client everywhere.

Miklos_Hollender · 2006-07-03

I think objects that have not been changed won't be recompiled. I mean a typical "make" system could do that 25 years ago on Unix and I assume 25 years is enough for MS it discover it

However, there is another problem with the recompile all stuff: how will teamwork be handled, as Joe working on Object X will recompile Object Y Jill is working on? By SVN or SourceSafe checkouts/commits with the painful manual text export/imports?

Miklos_Hollender · 2006-07-03

Kine,

are you completely sure that "generated C#" is not just the fob bytecode as data packed together with the same interpreter as in fin.exe?

kine · 2006-07-03

Miklos Hollender wrote:

Kine,

are you completely sure that "generated C#" is not just the fob bytecode as data packed together with the same interpreter as in fin.exe?

Of course, I am not sure... :-)

But I remember some info about "translating C/AL into C# and compiling the C# code" and Not "interpret C/AL in C#". But I don't know more details about that and it is some time ago...

Miklos_Hollender · 2006-07-03

OK. We'll see. I just guess it because I remember vbrun.dll which was the VB interpreter, while VB look like as if been compiled

ara3n · 2006-07-03

kine wrote:

C/SIDE vs. Dynamics 3-tier client : You will be able to use BOTH clients in one Environment (there is big OR, not XOR)! It means - you can start some Customer on C/SIDE and shift him step by step to new Dynamics Client as you will create the new Forms and Reports for this new client. For example, all users will be using C/Side client just management will be using the Dynamics Client to see their graphs and KPI, after some time, you will prepare new "Pages" for Warehouse etc... After some time, when your company prepare whole your solution for the new Dynamics Client, the customer will be using this client everywhere.

What is the purpose of form transformation tools? I thought this will transfer most of the forms to Pages. I know there will be some tweaking but that will part of the upgrade.

On another note, Somebody asked about techincal upgrade. and It could be possible, but you will loose some functionality. Matrix forms etc that will be gone. And it won't as straight forward and you have to fix a lot of things.

On Workflow. In one of the screenshots You can see a menue for Workflow. So they have implemented something

Miklos_Hollender · 2006-07-03

Lose matrix forms? Gee. How will the new client display Accounting Schedules & the like?

Marije_Brummel · 2006-07-03

Have I missed something? :? Loosing matrixforms?

Just because it is not yet built into the new client it doen not mean it will not be there. Filters also have not been implemented. The presentation is a PREVIEW of the new client. Not a final product, not even a Beta!

Let's be happy they share this information very early and not spread roumors about what will and will not be in the new version.

There. Thats all I have to say for now.

ara3n · 2006-07-03

I remember hearing it 6 months ago, and I remember they said, they will ahve somethign else instead. I could 100 % wrong on this, so I won't say anthing about anymore. :-#

jesam · 2006-07-04

To Miklos :

I don't think C/AL truly gets compiled to a C# in a keyword by keyword way.

I never said that. I think they compile it down to MSIL.

I think they simply wrap together the bytecode as data and the interpreter.

That would mean they execute Navision bytecode on an interpreter that is built in MSIL which is JITted. While techincally possible, I can't see this breaking any speed records, and it would still mean that they need to support two platforms/technologies instead of one.

.NET/CLR was created as a common platform for applications to talk each other that are built in different programming languages

No, it is a runtime environment and Base Class Library for MSIL code. The languages just get compiles into MSIL. You can see it as a replacement of COM.

It would be an outdated approach to directly instantiate a .NET class of Item from an assembly, because it would mean your application must be installed at the same server, also running in .NET and so on.
...
There will simply be no reason to instantiate NAV class directly unless you need something with an exceptionally high performance (but in that case I'd rather read the database directly). This is the concept of SOA.

SOA is one of the latest buzzwords, and while it certainly has some merits, it does add a lot of overhead. If you're developing inside a company, you really don't want to make every subsystem communicate through webservices with each other.
By the way, it is possible to have the concept of SOA while still having one big codebase that is compiled on the same platform.

The concept of many languages running on .NET is getting to become deprecated a bit - VB.NET for beginners and C# for everybody else and stuff like J#, Jscript.NET are getting less and less attention.

The many languages are a side-effect, not a goal as such. But I disagree with you. There is a Ruby On Rails coming for the CLR, we also have IronPython, and many more languages. By the way, VB.NET is not a beginners language, it's just a languages that has the same kind of power as C#, but with more verbosity (which some people actually like).
And yes, through Indigo you could communicate with other systems that are built in another language on another platform, but why would you do that ?
When you live in Deinze, you could get to Budapest via Vienna, you could also go via Moscow. If the two options are open to you, I think the choice is obvious.
(And please, Service Oriënted does not equal to exposing your functions/methods in SOAP/WSDL web services, the latter could be a part of SOA, but it does equal it).

To ara3n :

You probably have to reboot IIS and everybody will loose connection.

While I can't say for sure in the Navision case, I think they use the same technology they allready developed and host the middle tier assemblies in IIS so that the presentation tier can communicate with it through Indigo (WCF). In that case, uploading new DLLs does not require rebooting IIS. All active requests are seerved with the existing DLLs, a new AppDomain is created and the new requests are served with the new DLLs.

Miklos_Hollender · 2006-07-04

That would mean they execute Navision bytecode on an interpreter that is built in MSIL which is JITted. While techincally possible, I can't see this breaking any speed records, and it would still mean that they need to support two platforms/technologies instead of one.

Of course that would be a better way, but I doubt they could pull that off in such a short amount of time. Of maybe it's easier than I thougt, maybe it's just a one-by-one mapping of fob bytecode to MSIL bytecode.

I don't think speed is important in this case. 95% of the speed cost is still the database operations and it will stay this way until somebody finally figures out how to make big and fast flash drives cheaply or somebody figures out how to setup an SQL server the way that it holds all the master data and last 3 months of transactions paralelly on disk an in memory on a kind of virtual disk in memory (I was thinking about that, it could be lightning-fast if it could be pulled off).

If you're developing inside a company, you really don't want to make every subsystem communicate through webservices with each other.

It depends. If it has multiple sites, then it can make sense. The hardest part way always communication between physically different sites - all the replication strategies I know are not very usable - f.e. a friend of mine had a complete hell of setting up Landsteinar Scheduler, it took weeks... SOA might help in such things.

The many languages are a side-effect, not a goal as such.

In the early times, it was heavily marketed, to be able to leverage existing VB/C++/Java skills.

There is a Ruby On Rails coming for the CLR

Are you sure? All I heard of is a clone in C#, called MonoRail.

Dynamics Nav 5.0 Preview Presentation TechEd

Comments

Categories