I have received some really great feedback on the beta release of the AX TFS build library, and obviously also some reports of issues.
Since we heavily rely on TFS and builds here at Sikich, we are obviously facing these issues on a daily basis, and are trying to come up with different approaches to overcome these issues. The biggest issue we've faced so far is the importing of Visual Studio project into AX, which is what I'd like to talk about in this post.
When using source control, Visual Studio projects - as opposed to other objects in the AOT - are not stored in the source control tree as XPO files, but rather as their actually Visual Studio files (.cs files etc). This has some great advantages, however it becomes an issue when these projects need to be imported back into AX, based on the source control tree (in our case, during a build).
Now, AX does support the exporting of VS projects from the AOT as XPOs. So, first thing we tried was creating XPOs from VS project files. This involves some minor "wrapping" of the files with XPO "tags", and for binary files the hex-text encoding of those binaries into a text-based XPO. We were successful in doing this, and the XPOs import just fine into AX, however there are certain types of VS projects that create sub-folders (eg for service references and their datasources). And although these "XPO-encoded" VS projects import fine from the UI, they somehow fail to import from the command-line import that we use for builds. We've actually tried to command-line import an XPO that AX generated, and even that did not work... (the project does not show up in the AOT, and the import log shows an error "Unable to find appropriate folder in the AOT for this element" and "unknown application object type").
There are other methods to import code though. For example, using autorun.xml files. However, when we tried this it resulted in the exact same behavior. Since there is different behavior between UI and command-line import, I will report this issue to Microsoft.
If you think about it, the "synchronize with source control" feature in AX somehow is able to get the VS project files out of source control and import them back into AX, so there has to be a way... And indeed, there is: \Classes\SysTreeNodeVSProject::importProject() This static method is able to import a VS project and all its files directly, without the need to convert to XPO! And static methods can be called from an autorun.xml file, so we have a solution!
Once that was done, we were facing the next challenge... The way we are importing the combined XPO using command-line, AX is instructed not to do a compile when done. The reason for this is that AX actually does a full AOT compile, and doesn't just compile the elements being imported. But, it also skips compiling the imported objects, and so the import of the VS project works, but the VS project cannot be built if it relies on proxies for classes that were imported (but not compiled). When you then run a full compile, the X++ classes will not compile because of the missing assemblies (assuming you are using your VS project in X++ somewhere of course). So this seems like a vicious circle; even if your code is not circular in reference, the compiles will fail (perhaps multiple compiles in row will eventually work, but how much total time will that take?).
Bottom line, it would help tremendously if the X++ artifacts being imported would compile during import... The only way we seem to be able to do that, without a full compile, is using autorun.xml again!
So basically, we now have a need to use autorun.xml to instruct commands to AX, rather than a straight-up command line call to ax32.exe. In itself this is not an issue, but of course we were not using autorun in the build scripts at all, up to this point.
End result is a change in workflow (and change in philosophy a little bit perhaps) to use autorun XML files.
Coming soon to a CodePlex update near you.