A few months ago I wrote a post on how to convert Excel documents to PDF with X++. Well, that piece of code made it into production! But I just notice it does not necessarily compile with Ax Build.
The xlApp declaration does not compile because Excel is not installed on the server and AX build can only be completed on the server. If you compile this same piece of code in the AOT on a server that has Excel installed, it compiles without a problem.
- Install Excel on the server. I am not sure if this will allow AX Build to compile the code, but at least you can then open the AOT after AX build on the sever and compile like I described here.
- Since I could not install Excel on the server, I did the following:
- Compile with AX Build on the server.
- If you have a compile error related to Microsoft.Office.Interop.Excel, start the server and open the AOT on a terminal server that has Excel installed.
- Compile the code with normal F7 compile.
- Compile the CIL on the terminal server.
Hope that helps! Let me know in the comments if you know of a better way to solve this.
Today marks the end of my first year as a Dynamics AX developer! On the 1st of March 2014 I started working for a Microsoft Dynamics AX partner and I saw Dynamics AX for the first time. I had some development work experience before I started, but that was mostly maintaining very old VB and C# code.
I have learned thousands of things since I started! To keep it brief and celebrate how far I’ve come, here are 10 thing I learned about developing in AX this past year:
- I learned to write ternary statements. How I wrote software without understanding ternary statements is a mystery to me now.
- Ctrl + Arrow key moves the curser to the next word. This seem silly, but no one every taught or showed me this. I used to click with the mouse or move the cursor character by character with the arrow key.
- Developing in Dynamics AX is 90% searching and 10% developing. Even if you need to add one simple line of code, you will most likely spend 30 minutes looking for the correct class, table or form method to add the line, and then spend less than 3 minutes writing the code.
- It is much harder to find solutions and answers with Google. Not all of my colleagues agree with me on this, but I think it is because they have never googled for a Java or C# issue. With more popular languages you have a much bigger chance that someone had the same problem as you.
- Since it is more difficult to find recourses and beginner guides, the easiest way to learn is from someone with more experience. I have completed Microsoft Development training and have read blogs, books and forums. They were all great, but I have learned the most from working one on one with a senior developer.
- No human being should be working on a computer without Ditto Clipboard Manager. This includes people who uses computers to write email and write in Word. I dare you to try it. It will change the way you copy and paste forever and make you wonder why Windows 1998 wasn’t released with a clipboard manager.
- It pays to write neat code. Write curly braces for every if-statement, indent properly and run a best practice check often.
- Triple check code when you copy methods from the sales to purchase or customer to vendor. Also, you should only be doing this if is impossble to use a map like SalesPurchLine or SalesPurchTable. A senior emailed me this screenshot.. oops!
- Writing SQL like statements in X++ is simple and intuitive. I hoped this was a deprecated Axapta relic when I saw it the fist time, but know I know how simple and effective it is to find data in the database.
- I have learned that I still have a lot to learn. Working with extremely competent people with years of experience have taught me that this is only the beginning.