source code

summerzz

is the dynamic source code going to be given to customer?

Alex_Chow

for NAV, you have access to the source code if you purchase the full developer license.

MTC

Alex Chow wrote:

for NAV, you have access to the source code if you purchase the full developer license.

Do we know this?

I'm still not to sure if C/AL objects will be distributed to end clients without a developer's licence, rather the .Net MSIL bytecode binaries. You shouldn't be able to compile anything without a developer's licence, and you shouldn't be able to run anything without the MSIL bytecode objects on the middle tier.

Then again, how could you edit or modify the code without the C/AL objects in the BLOB Refernce field of the Object table?

Someone may like to explain to me exactly how this is going to work. We know that we will not have the C# code available, so development must be in C/AL. Now, is decompiling an MSIL bytecode object as easy as it is in Java? If so, you have a two way conversion process that could possibly go on and there will never be the need to store any C/AL objects at all in the BLOB Reference field. The C/AL would be generated automatically, or in the case of Axapta the X++ generated automatically from the MSIL binaries. There would never be the need to actually store it.

Alex_Chow

Umm... You can just highlight everything and export all the objects as a .txt file. Or am I misunderstanding your point? :-k

MTC

Alex Chow wrote:

Umm... You can just highlight everything and export all the objects as a .txt file. Or am I misunderstanding your point? :-k

He's talking about 5.1

I don't know about you, but I've not seen how it works on this level or had any access to documentation saying how it is going to work. Does the end client (if by customer he means end client) get the C/AL objects or not? Do C/AL objects even exist for the developer, or is it decompiled from the MSIL?

I've not got a clue. All I know that is you write in C/AL and compile a always. However, when you compile, does it still compile the C/AL object as now into the object found in the BLOB Reference field of the Object table and then convert that to C# before compiling the C# to MSIL, or does it simply take the C/AL, not compile them as now so you have no C/AL compiled binary, and simply convert the C/AL source to C# for compilation to MSIL?

If the process can be done in both directions as it can very easily be done in Java, then there is never any need to store C/AL code anymore, and definitely no need to store the compiled part of the C/AL code.

MTC

What I'm saying here is that it should be posible to turn the object into whatever language you want it to be turned into.

This must be the way that they are going if they want to merge the current four Dynamics ERPs into a single system with the option to still develop in C/AL or X++ or whatever, I know very little about the two American products.

DenSter

You don't need MSIL, or C#, everything is going to be in C/AL, just like it is now.

MTC

DenSter wrote:

You don't need MSIL, or C#, everything is going to be in C/AL, just like it is now.

But it all runs on the middle server which doesn't understand C/AL correct?

That's the point! If you program it in C/AL that's one thing, it doesn't mean that it will save C/AL because it will use C# and MSIL to generate the executable that will not run within the client.

Unless I am missing something here.

David_Singleton

MTC wrote:

...Unless I am missing something here.

Which part of :

DenSter wrote:

... everything is going to be in C/AL, just like it is now.

Did you not understand? :?:

MTC

David Singleton wrote:

MTC wrote:

...Unless I am missing something here.

Which part of :

DenSter wrote:

... everything is going to be in C/AL, just like it is now.

Did you not understand? :?:

What is it doing with C# then? Are you saying that the middle tier will use C/AL instead of MSIL binaries?

Do you have a specification document? You seem to know how it will work.

The TechED document I have seen says Application code is still "Written" in C/AL; C/AL is "translated" to C# code and compiled into a managed assembly; Developers do not "see" C#.

Which part of that do you not understand? Or have things "changed"?

I'm simply asking whether the C/AL is actually stored anywhere and if it is still compiled, or is it generated on the fly? To a certain extent it is generated on the fly now.

Sorry to have engaged MVPs in such trivial matters and for not taking their word as gospel without question.

David_Singleton

MTC wrote:

...

Sorry to have engaged MVPs in such trivial matters and for not taking their word as gospel without question.

Well nothing is too trivial, so don't get the wrong idea. Your question has been answered by Daniel very clearly, but you want a different answer.


But the point here is to concentrate on what is important.

Navision used to use p-code as its internal language, but that was never made public, and it really did not matter, since even though it was not too hard to get access to it, there was not much you could use it for.

In Dynamics NAV 5.1 its the same. Yes there is an internal step that generates and compiles C# code, but its totally irrelevant, since you wont be accessing it, you will still be doing all your development in C/AL.

The big problem is that at Directions, they showed this C# code, and some how a small but vocal part of the Dynamics community ran with it, and it has caused confusion ever since.

So for the record:

In Dynamics NAV 5.1, developers will use the same C/AL code they have been using in all past versions of Navision. The only change is that you will have a new Object Type for designing pages, and you will be able to do report layouts EITHER using the current Report Designer, for the 2 tier client, OR with the new report designer for the Three tier client.

If you need (or want) to use C##, then write a wrapper around C/FRONT to do this.

Anyway, we do want to help you, we just don't want to argue with something that is fact. So lets keep this nice and friendly

DenSter

The middle tier will live somewhere in the system as managed .NET assemblies that will be generated by saving the C/AL object. Internally, it transforms the C/AL to C# and compiles it directly into managed assemblies. It is not relevant what happens in between, because you will never see any of that.

You will only see C/AL, just like you do now. You will not need to write any C# as part of normal NAV development. Not ever. C# will NOT be part of C/AL development. It is Microsoft's stated goal for the partner channel not to have to learn a new development language for 5.1. It is not going to change. Stop speculating that it is

Of course there's that new thing in 5.1 called web services. You can use any development tool to consume those web services, so if you consider that as part of 'normal' NAV development you could say you will be using C# if that it your language of choice.

MTC

I think somebody is misunderstanding me here. The original question was whether the source code was distributed to customers, in which I suppose he meant the end client. The actual business that uses the system.

People seem to think I have a thing about C#, to be honest I couldn't care less about it.

As for the BLOB field that currently stores both the "compiled" C/AL byte code, and parts of the C/AL source code, I've been working a month or so on and off (my main job is upgrades, and support to programmers and analysts to produce quality systems, along with investigations into highly technical matters) to try and reverse engineer the BLOB. I'm quite aware how that works, and also what the problems are with it. I currently understand around 80% of how it works, and can extract source code from it without a problem. I'm only having problems inserting new source code into it.

Before you all throw your hands up in the air and start shouting why. Well, a lot of partners ask for certain functionality or features that technically cannot be achieved through the NAV client as it is. I really do not know how much I can say, but I work for one of the very few partners that do not try to sell the product, we offer services to the partners that do sell the product be it NSC or ISVs or whatever, and even to Microsoft themselves. I'm not saying any more on the last point, but even they under pressure of their partners ask for silly things to be done. One example is a log of view which the law here requires for such things as salaries. You either get Denmark to change it (the client), or you try to break it, possibly with Microsoft collaboration, possibly not, which I have done. Anyway, enough of that.

I'm not a NAV consultant, although I do know the flow of its processes across the board. I don't need to know how to configure it to work, I don't need to, a consultant does that. A programmer needs to do something I help them. That is what I do.

I don't actually want to do anything in C# with NAV, I want to know if I still get my BLOB!

That's the point of my question. If MSIL, and I don't know this which is why I asked is as easily decompiled to code as Java's byte code objects are, then there is no need to store C/AL anywhere.

Think about it chaps. They have a dream of merging 4 products into one, yet cannot dump the likes of C/AL or X++. So, at some point what do they have to do? Well, they have to give all the 4 systems the same functionality, then they have to have a way of turning that exactly the same functionality into different source codes. They might as well start dealing with this point now. If all four "translate" their source code to C# there is a standard compiler - if you can do the process in reverse (Java makes it very easy to do so for many reasons), then you can continue to develop the system in whatever language you like. And I do not see a problem of allowing you to develop for Dynamics in C/AL or X++ for as long as Dynamics actually has a life.

I am not asking if we will still develop in C/AL or not! And I do not want to write for NAV in C#.

I hope the last paragraph is quite clear.

MTC

I must say, that my reverse engineering of the BLOB will never be used without the consent of Microsoft and that it will never be distributed in any form whatsoever.

Just to make that point clear.

summerzz

yes, in fact my intended question was will the client (end consumer of Dynamic) ever be given source code. If yes, how about when they upgrade from 4.0 to 5.1, will source code also be given to customers?

How feasible is it for customers, not Dynamic Consultant to ever perform self-customization?? Just wondering if this is acceptable.

DenSter

I still don't get why you don't seem to understand.... All development wil be done in C/AL, and yes the customer will get the source code. Not the application source code, but the business logic source code. Just like it happens now.

Alex_Chow

summerzz wrote:

yes, in fact my intended question was will the client (end consumer of Dynamic) ever be given source code. If yes, how about when they upgrade from 4.0 to 5.1, will source code also be given to customers?

How feasible is it for customers, not Dynamic Consultant to ever perform self-customization?? Just wondering if this is acceptable.

Yes, having the customer doing customizations is encouraged by Navision. This was one of the strong selling points in that the end user can make changes to Navision without having to pay for a consultant.

summerzz

i understand that end user can customize, in the sense that they can add in fields/column but what about if the customization invovled the building in of new workflow/logic with programming implications?

Eg, if i buy NAv 4.0 and self-customize some workflow/features into it and later decides to upgrade to 5.1, will the part that i self-customized be compatible with 5.1? OR i have to give up what i self-customized and re-programme in 5.1 again?

Thanks!

gedas

Yes, there are differencies between old and new clients. For example all NAV reports will be transfered to SQL reports which has no section triggers, transheaders code and so. If your code is based on this, you need reprogramme it. The same is for forms, and changes are in automation usage, temporary tables...
So will you need to reprogramme your code depends on code: maybe yes maybe not.

MTC

DenSter wrote:

I still don't get why you don't seem to understand.... All development wil be done in C/AL, and yes the customer will get the source code. Not the application source code, but the business logic source code. Just like it happens now.

I think that the premise of my question keeps flying over your head. You are either not actually reading what I am asking about and rather making assumptions about what I am asking, or you are purposely ignoring what I am asking. So we will leave it at that.

MTC

Or, one last time.

Is the C/AL code still stored in the Blob-Reference field in the Object table? If so, is it also compiled there as it is now?

DenSter

MTC wrote:

DenSter wrote:

You don't need MSIL, or C#, everything is going to be in C/AL, just like it is now.

But it all runs on the middle server which doesn't understand C/AL correct?

That's the point! If you program it in C/AL that's one thing, it doesn't mean that it will save C/AL because it will use C# and MSIL to generate the executable that will not run within the client.

Unless I am missing something here.

Maybe I am getting senile and missing the thing you really mean when you're taking about C#

You are making assumptions about C# and MSIL, and wondering all these exotic things about how and where the code lives. I am telling you that this is not relevant information, we will be developing in C/AL. I am also telling you that C/AL gets translated into C# that nobody is supposed to see, that is not ever saved anywhere, and then automatically compiled into managed assemblies.

I could repeat myself a second time, but that's all I can say about it. I'm not trying to ignore you, so if you feel that I misunderstood your question, maybe you could summarize all the things you want to know in a list, very specifically, and I will try to address each point individually.

jesam

or you are purposely ignoring what I am asking.

Welcome to the brick wall of MiBuSo. This is (without cynism) a great side if you are Navision minded and willing to play within the Navision set of rules. It's not only a great site, it's about the only site.

But as soon as you wake up from The Matrix you hit a brick wall.
Do you think Navision has an editor not worthy of that name ? Well that's because you're not supposed to program in Navision, only customize.
Your NSC nevertheless changed loads of standard code ? Too bad for you, you had a bad NSC. Off course anybody can call himself an NSC, so it's really a lotery.

Do you think Navision has a mediocre programming language that lacks OO stuf ? Too bad for you, as you're not supposed to program in Navision that shouldn't be a problem. And who needs OO anyway ?

Do you not like the way that Navision is such a two tier system ? Too bad, there's nothing you can do.

Do you wonder why the toolbox shows a ListBox Item that never is enabled ? Who needs a listbox anyway ?

And do you wonder how Navision does something that is not documented ? That's blasphemy, if you're not willing to play by Navisions rules, then leave it alone, and please, don't ask questions.

David_Singleton

jesam wrote:

... It's not only a great site, it's about the only site.
...

Well there is also http://dynamicsuser.net

DenSter

jesam wrote:

Welcome to the brick wall of MiBuSo.

I am truly sorry that you are not happy with this site, I can assure you that everyone that I know that posts here wants to help as much as possible.

For me personally, I would rather talk about what IS, than speculate about what SHOULD or COULD BE. I just don't think there is any benefit in saying bad things about something because it doesn't have this or that attribute.

Why would you complain about a red bicycle that it isn't green? It's a red bicycle, that's just what it is.

Most people on this site (yes David and the other one too ) are more concerned about making the system that we have work, rather than endlessly complain about what it is not, or speculate about what it will be in the future.

I see this to state my opinion, and I respect Jesam's, I just don't agree with it.

Alex_Chow

Maybe Microsoft should just release a statement saying that C/Side is created only for development within Navision. NOT anything else.

I haven't encountered any business problems that cannot be resolved through Navision's development environment (knock on wood). Whether or not Navision can only developed in C# or not, doesn't really matter as long as the business requirements can be satisfied.

But I think MTC's originally question was asked out of curiousity. Yes, the code is still stored in the BLOB field, and no, you won't be able to access the C# code. By the time it's compiled, it'll be in .DLL format.

Mbad

Answering the questions is always a good way of ending discussions. Well done Alex

Oh and can I have a green bicycle?

DenSter

Mbad wrote:

Answering the questions is always a good way of ending discussions. Well done Alex

Oh and can I have a green bicycle?

Sure you can, as long as you don't start complaining that it isn't red

oh and the question about where the code lives was not the original question.

Savatage

Wh'd I miss? 8-[ I should start paying more attention to the 5.1 forum

Alex_Chow

Savatage wrote:

Wh'd I miss? 8-[ I should start paying more attention to the 5.1 forum

You didn't miss much Harry... Must of the posts on here are assumptions and "I heard blah blah blah" kind of deals.

Waldo

jesam, really, are you still working with NAV?

I thought you would have changed by now. Seems like deep down you just can't get enough of it