Posted By: Charles | Sep 1st, 2009 @ 9:27 AM | 47,855 Views | 8 Comments
Dynamics Program Manager Peter Villadsen and Software Developer Gustavo Plancarte teach us about a new tool they've developed that translates X++ byte code into MSIL. We learn a lot of history along the way and gain insights into the process of taking X++ into the .NET age.

Microsoft Dynamics features a proprietary language called X++ (basically a superset of Java, with some strong data primitives added) and a complete stack (compiler, interpreter and debugger) that goes with it. The new feature Peter and team have developed is a tool to generate managed code from the X++ intermediate language produced by the X++ compiler. This will have profound impact on the performance of the business applications written in X++, and it very clearly points to where they'll be going in the next few releases of Dynamics Ax.

Tune in.

Rating:
0
0
Klaus Enevoldsen
Klaus Enevoldsen
Development has never been easier nor more complicated...

Nice way of handling the transition from X++ to MSI - good thinking...

I would assume that this is going to be for the "server" code. Or are you also looking at the ability to move the FORMS to IL?

I think it's very good Idea. I don't know why, but I feel it has more hidden obstcales. Like Forms and Reports. Eventually I wish it successed.

I think you are right mate, they wold probably favour dropping the proprietary X++ AX reports in favour of SSRS but as for the forms, at some level the forms are classes that implement a windows object so it shouldn’t be too difficult.

 

Have you got an approximative time line of when X++ will be completely dropped out ?

5 years? 10 years ?

 

Where can I find a (technical) platform transformation roadmap for AX ?

 

Best Regards from France,

Tarek Demiati

 

A Freelance Dynamics NAV, interested by what AX has got to offer

Why is the approach taken to de-integrate everything in Ax? It's strongest point is the fact that you have a single tool-set for everything and now the direction seems to be moving away from that. When you rely on other tools (eg SSRS) you're effectively introducing a new system and interface, and there will always be a disconnect between the two. Is it just to incorporate as many technologies as possible as opposed to actually improving developer productivity? I am honestly, yet to hear a solid technical argument for this approach as opposed to marketing based 'xxx is the future'. The day-to-day issues that come up with installing all of these systems (SSRS, Sharepoint, EP) and the problems that occur from differing versions/service packs/etc are constant and very frustrating. And at this point (V2009) the tools and integration are not as solid or reliable as one would hope. In terms of 'dropping X++ reports' - I shudder to think what the SSRS implementation of something like financial statements or the highly procedural/configurable reports would be like.

 

 I'm generally interested in the overall approach and reasoning as this is my day-to-day work.

Microsoft Communities