When you write code in Visual Studio (VS) you can write in many different languages, Visual Basic, C#, F# - there are lots of choices. In VS when you build or compile your project
those languages are all mapped down to a different language - the Common Intermediate Language. That means if you are writing in Visual Basic your if/else statement in Visual Basic becomes whatever the equivalent is in CIL. The Common Language Runtime (CLR) that ships with .NET understands the Common Intermediate Language and knows how to execute that code. The CLR does not need to understand all of the different languages (like C#, VB or F#) it needs to only understand the one language they all get mapped down to, CIL.
In AX you program in X++ and the equivalent of AX's CLR is the kernel. When you build or compile your X++ code it traditionally gets mapped down to a p-code language that the kernel understands and knows how to execute. In AX 2012 for certain classes that is what has changed. Now when you compile the X++ code gets mapped down to the Common Intermediate Language. Then the CLR understands what the code says and executes it - the kernel is not needed.
Please note that I took the diagram from a book, but I modified it to my own needs.
As you can see, now we have the ability to compile P-Code to CIL, and therefore AX 2012 is able to run X++ code directly into the CIL, which is much faster the P-Code compiler we had before.
n AX 2012 there are two different kinds of compiles you can run: a full or an incremental compile. A full compile goes through all of the X++ code in your AX environment and compiles the classes that run in batch and service classes down to CIL. A full IL compile takes a lot of memory! You'll need at least 4 gig of memory free on the machine and I'd get more if you can. If you are trying to run a full IL compile and your system keepscrashing, you need more memory. An incremental compile maps all of the service classes and classes running in batch to CIL that have changed since you last ran a IL compile. While you are doing development work you generally only need to do an incremental compile since when your system was installed part of the checklist involves running a full compile.
Clearly incremental CIL and the full CIL compilation. The major difference between the two of them is that the incremental CIL would compile only the objects that were modified since the last incremental compilation. For what I have learned, the full CIL generation is mandatory when we do modify anything on the XppIL folder.
If you are having problems doing an incremental compile I would dig into whatever errors the compiler is giving you, you probably have something wrong in your code. When you build your code with the X++ compiler (the compile button on the toolbar) that compiler is less stringent about what qualifies as a compile error than the IL compiler is. If the X++ compiler compiles successfully but when you go to the Build > Generate Incremental CIL option it fails, you likely have an issue in your code. Look at which line the error message says is wrong in the description field of the output and not at the line field.
if you get IL compilation errors you should stop and figure them out before you proceed. If your code does not compile, you will run into issues where you have modified a class but your modifications are not being used or when you call a service it does not see your changes.
Your changes are not being seen because they have not yet been compiled down to IL code and therefore the CLR does not see them and is not trying to execute them.
On the XppIL folder, I noticed that we have a bunch of files there. These files are NetModule type files and they only contain type metadata and compiled code. It is important not to confuse a NetModule type file with .NET assemblies, as these contain and assembly manifest and managed code.
Now the really interesting portion of this is that within the XppIL folder there is a folder named “source”, and within this folder we find a bunch of files with the .xpp extension, which have x++ source code and are used to debug CIL code in Visual Studio when working with services and batches.
Further, another interesting point to this is that the “existence” of the source folder is directly related to our server configuration when choosing to enable debugging on the server.
No comments:
Post a Comment