Wednesday, May 9, 2012

Announcing: AX TFS Build Library

As you know I started a project on CodePlex last year, sharing our internally built scripts to automate builds for AX 2009. Obviously with the release of AX 2012 and new ways to release AX code (models!), we had to change our build scripts.

And with change comes the opportunity for improvement. We have taken the build process a step further and created workflow code activities for use with the TFS 2010 build server. If you want to dive into it, check out the beta release on CodePlex. Note this is a beta release, and particularly the AX 2009 code is not tested thoroughly.

What does this mean, code activities? Once loaded (see below), you can drag-and-drop Dynamics AX build activities in your workflow, and compose your own build template. Below screenshots from the AX 2012 build script included in the beta release.

This release includes the following code activities you can include in your build scripts:

There is a lot to talk about on this topic, including more documentation on how to use these activities. For now, feel free to download and try out the sample build template included! To be able to use these activities, you need to add the assembly DLL file to your source control on TFS somewhere, and point your TFS build controller to that server path, as explained in this blog post under "Deploying the Activity".

Stay tuned for more documentation, information, tips and walkthroughs on automating your AX builds!

Friday, May 4, 2012

AxUtilLib.dll Issue with .NET 4

I ran into the following issue, which is now reported and recognized as an official bug by Microsoft.

When you use the AxUtilLib.dll assembly from a .NET 4 project, you can manage models from code. However, the DLL file is built against .NET 2.0 runtime. This poses no problem as those assemblies can be run in the .NET 4.0 runtime. However, when you export a model using this library in a 4.0 runtime, the exported model will be a.NET 4.0 assembly instead of a 2.0 assembly. When you then try to import this model using the powershell cmdlets or the axutil command line utility, you receive the following error message:

ERROR: The model file [filename] has an invalid format.

When you try to view the manifest of the model file, you get the following error message:

ERROR: Exception has been thrown by the target of an invocation.

When you open the axmodel file using ILSpy (remember the axmodel files are actual assemblies), you will notice that the model is a .NET 4.0 assembly, whereas a "good" model is .NET 2.0:

You will see the same behavior if you use the 2012 PowerShell cmdlets from PowerShell 3.0 (currently in beta). There is currently no fix for this, the only workaround is to use the command line utilities. Note that all other features work perfectly, including importing the model.