Cleaning up after AxBuild.exe

So the AxBuild.exe tool has been around for a couple of weeks now and imho this is the best addition that a CU brought until now.
There have been some nice post about how it works and what you should keep in mind:
Though the tool is fantastic, we noticed that after performing a compile we always needed some manual actions to get the error count to 0.
Due to the limitations of AxBuild we always had approximately 100 errors left after compiling. A lot of them were custom .Net assemblies that could not be referenced at compile time.
So here is what you normally do when performing a full compile now:
  • AxBuild your environment
  • Import the HTML compiler output
  • In the compiler windows, select create project to create a project with all of the objects that were still invalid
  • Compile the project inside the Ax client
Well, just to make it easier, I have created a little tool which does the last 3 actions at once so that we do not need to perform these things manually. (And enabling us to incorporate it in automated builds).
The idea is to have a startup command which I can use like this :
ax32.exe -startupCmd=importandcompileaxbuildlog_<Full path to the exported compiler log file>
Due to the nature of the (imho not so good) design of the startup commands, it is not possible to enter a file path with spaces in your command prompt. Also putting quotes around it wouldn’t help too.
Therefor I have used the ‘*’ sign and the startup command will replace the ‘*’ charaters with spaces. For example:
ax32.exe -startupCmd=importandcompileaxbuildlog_C:\Program Files\Microsoft*Dynamics*AX\60\Server\AX60R2\Log\AxCompileAll.html
If you want to try it yourself, you can find an XPO containing the code here.
  1. November 24th, 2013 at 18:40 | #1
    Wouldn’t /altbin parameter help with your problem with assembly references?
  2. November 28th, 2013 at 10:02 | #2
    True, Joris also mentioned this. I am currently checking why the altbin doesn’t help me out here since it should actually.
    Thx!
  3. December 5th, 2013 at 11:03 | #3
    Thanks. It works great. This solved my remaining issue’s with the full compile
    Afterwards CIL compilation finally worked again
  4. Gert
    December 5th, 2013 at 13:09 | #4
    why are you having the second parameter in here:
    newParameters(TreeNodeName _projectName
    # , SysCompilerOutput _sysCompilerOutput)
    it’s not used anywhere in the method?
  5. December 5th, 2013 at 13:57 | #5
    It is just so you can pass custom compiler output if you wish. (I have created a custom compiler output and it contains extra information and if it is needed to use it, you can put a parmCompilerOutput there to pass it to the rest.
    regards,
    Kenny
  6. Jesper Dybdahl
    December 13th, 2013 at 13:08 | #6
    I was told that a custom reference to the v4 of the system assemblies in the AOT would do the trick as AXBUILD is .net v2 as opposed to the client v4. Didn’t make any difference for me, but I might have gotten it wrong. Also, I am not in favor of having a customization only for the sake of making it compile. I’ll use your method for now. Thanks for sharing.
  7. December 13th, 2013 at 20:36 | #7
    I agree with ‘not in favor of having a customization only for the sake of making it compile.
    For now I am using it as an ‘in between solution’
  8. Gin
    January 10th, 2014 at 15:57 | #8
    Do you know guys if MS is aware of that glitch with axbuild.exe and if there a ticket open with them?
  9. Gin
    January 10th, 2014 at 19:26 | #9
    Oh I see! We only have to start axbuild.exe as an admin, works great now! :)
  10. March 18th, 2014 at 23:41 | #10
    Hi, Most of the time using the AltBin directory switch is usefull and helps you reduce the number of issues to 0.
    Kind regards,
    Mehrdad
  11. ganesh
    May 5th, 2014 at 18:11 | #11
    You need to turn off the AOS and do Compile using AxBuild so that you dont see any errors after the full compile.
  12. Ryan
    May 14th, 2014 at 20:38 | #12
    I’ve been seeing cases where I am getting a false positive from this operation. I’ve introduced a syntax error into a class and run AXBuild to compile. The AXcompileAll.html log has an error
    Error \Classes\Myclass\run 157 33 Operand types are not compatible with
    I can see that the private project does have the class present as well. When I manually compile the project from the AOT it very clearly encounters the failure above. However, when this process does the compilation, the updated log does not indicate any errors. Debugging the SysCompilerOutput::xmlExport method reveals that there is no data in the tmpCompilerOutput var
  13. May 14th, 2014 at 23:14 | #13
    @Ganesh: Hmm turning off the AOS, haven’t tried that one before. Good suggestion!

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.