Thursday, April 11, 2013

Solving the error " The CIL generator found errors and could not save the new assembly"

 

Hi There!

On this post I would like to discuss how to solve the CIL compilation error when deploying services for the first time in AX 2012. I have been working on a newly installed AX 2012 CU2 instance this week, and I deployed both basic and enhanced services.

This action was successfully done and I did not experience any issues. However, when I created a new service group and I deployed it, I encounter an error saying “The CIL generator found errors and could not save the new assembly”.



Now, this instance of AX 2012 is using a restored DB backup from another instance as I needed some data and objects already existing. It makes sense to think that this issue is true from the premise that I never went through a full AX and CIL compilation.

In addition, when generating the services through the installation, the references to the .NET Module File and the AX Application DLL were correct, but where they referring to the correct .NET Assembly types for the WFC generated endpoints?  I truly don’t know the answer to this and I asked for help.

My friend Bill Bartolotto (you can contact him here at his LinkedIn profile) went through this problem and he helped me solved it in my instance.  Bill has a vast experience in AX architecture and is really knowledgeable in AX 2012.

So, how do we fix this problem?

Step 1: Stop the AOS

Atep 2: Delete all of the source in the C:\Program Files\Microsoft Dynamics AX\60\Server\MicrosoftDynamicsAX\bin\XppIL directory

When you do this, just delete all the files within the XppIL folder that are outside of other folders. Make a backup just in case, and the files would be generated while the full compilation is taking place.



Step 3: Start the AOS



Step 3: Perform a full compile (it will not work without doing this)



Step 4: Perform a full CIL generation



The drawback of this fix is that it takes a long time to complete. However, this fixes the issue, which is the desired outcome, and the services deployment and incremental CIL compilations moving forward would be error free.

As you can see, the service was deployed correctly and if I opened my inbound port I'll see it there.



UPDATE:

After a FULL CIL compilation I got the following errors:

 
AOT > Class> ReleaseUpdateDB41_Basic
 
 
I just went to the object in question and compiled them separately.

 
 
The outcome would correctly compiled all the artifacts, including my new service gorup.



Until the next post!

4 comments:

  1. Normally when I get that error after doing an incremental CIL compile, I do a full CIL compile. If it still fails, it normally is due to compile errors in the AOT (x++), so that requires a full compile. When this doesn't help, it could be due to referenced assemblies not being picked up by the AOS, which in turn requires a restart of the AOS. I very seldom need to explicitly delete the files in that folder.

    So basically, in that order:
    1) Incremental CIL
    2) Full CIL
    3) Full Compile + Full CIL
    4) Restart AOS + Full Compile + Full CIL

    I've seen remnants of files in that XppIL folder, but I don't think they cause any issues. I guess cleaning them up doesn't hurt.

    One more location to clean up IL completely us the SysXppAssembly table (http://msdn.microsoft.com/en-us/library/sysxppassembly.aspx).

    ReplyDelete
    Replies
    1. Hey Tommy,

      Thanks for sharing your experience. I also that if you still get compilation errors after a Full CIL compile, we can just go to that object and compile it, and the issues also went away. I guess there are so many different ways to solve it!

      Again, thanks for taking the time to share with us your experience with this issue.

      Delete
    2. Yup, that is true. The CIL Compile log will reveal more information about what exact object could not compile. More often, you can save time by identifying what object needs to be compiled properly (or forward compiled), then Generate a full CIL. But sometimes, especially if many developers have changed code on the same AOT, you will have a long chain of dependencies being broken, and you are better off doing a full AOT compile. In some of the environments I work in, that process takes hours... :(

      Delete
    3. Yeah, in large development teams the objects would constantly change. I just wish that TFS would provide some sort of large scale global deployment tool that would allow an instance to be sync with the latest compilation every night. As far as I know, right now this process is manual, and time consuming. Perhaps Microsoft will solve this problem by 2014? We'll see.

      Delete

Thank you for your thoughts. Your comment will appear in my blog shortly after review.

Have a great day!