Peter Villadsen and Gustavo Plancarte: X++ to MSIL

Sign in to queue

Description

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.

Embed

Download

Download this episode

The Discussion

  • User profile image
    ecofriend

    J#+ or J-sharper? Big Smile

  • User profile image
    Klaus Enevoldsen

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

  • User profile image
    FrickMystr

    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?

  • User profile image
    DynamicsAX

    Interesting.....

  • User profile image
    m_anass

    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.

  • User profile image
    msaxapta

    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.

  • User profile image
    Sun Softworks

     

    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

  • User profile image
    getyaboogie​on

    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.

  • User profile image
    Max Mackmillian

    Where to find the XML add-in?

  • User profile image
    FitFit

    I agree with you. Ever since new techonologies were introduced into AX (SSRS, SharePoint ... etc) and I'm struggling with every installation to just make them work, let alone enhancing or customizing them. Our customers are yet to make the full benefit of these "good-looking" features. I'm by no means underestimating the prospects they'd bring and the possibilities they might open, however, the challenges they entail could put some partners in a not so comfortable situation (e.g. not having enough resources to implement and customize these technologies).

     

    If we look at how workflow has been integrated with AX we can get a good example of what would "feel" best for developers. But in the way things are going, the meaning of an AX developer will change from a person who knows the best of X++ and MorphX to a person who knows a bit about AX and other bits from a bunch of technologies and tools integrated with AX.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.