• About

Day 2 Day Dynamics

~ Experiences of a working AX developer

Day 2 Day Dynamics

Monthly Archives: August 2015

D2DDynamics custom PowerShell module

31 Monday Aug 2015

Posted by John Hagler in Powershell

≈ Leave a comment

Tags

ALD, AOT, Automation, AX, AX 2012, AX Artifacts, AX Database, AX Import, AX Label, Build Scripts, Compile, DB, Dynamics AX, PowerShell, PowerShell Module, R2 CU7, Server Compile, Team Foundation Server, TFS, XPO

The D2DDynamics custom PowerShell module is finally available in Codeplex.  The 1.0.0 version includes 15 exportable PowerShell functions and 3 internal helper functions.  They are:

  • Get-AXAutoRunXML
  • Start-AXAutoRun
  • Start-AXBuildCompile
  • Compile-AXCIL
  • Sync-AXDB
  • Compile-AXAOT
  • Clean-AXArtifacts
  • Import-AXXPO
  • Import-AXLabelFile
  • Sync-TFSWorkingFolder
  • Restore-AXDatabase
  • Combine-AXXPO
  • Start-AXMSBuildImport
  • Compile-AXXppNode
  • Import-AXVSProject

The 3 internal functions are:

  • Send-Email
  • Clean-Folder
  • Clean-Folders

This module is dependent on the 0.3.5 release of the DynamicsAXCommunity PowerShell module among others.  There are also some variables that should be set up in your profile if you are planning on using the functions.  The profile that I use can be found in Codeplex at Source Code -> Powershell -> Profile -> Modules -> Microsoft.PowerShell_profile.ps1.  Please use this as a reference for setting up your own profile.

To install the module, copy the D2DDynamics folder to the module folder for PowerShell.  On my Server 2012 server, the location is “C:\Windows\System32\WindowsPowerShell\v1.0\Modules”.  After the module is there, you should be able to open PowerShell and add it with the Import-Module cmdlet.

Future posts will include the steps necessary to create a custom build process using the module as well as more functions that can be used for deploying your build to other environments.  Please let me know what you think of the module and if you find any problems with using the functions in your environments.

Import-AXVSProject custom PowerShell function

18 Tuesday Aug 2015

Posted by John Hagler in Powershell

≈ 1 Comment

Tags

Automation, AutoRun, AX, AX 2012, AX Project, Build Scripts, Compile, Dynamics AX, PowerShell, Visual Studio

The Import-AXVSProject function is the second of 2 functions to support more complicated Visual Studio project scenarios.  I have taken this approach from here.  I don’t personally use this approach in my build as my current environment doesn’t require it but this function along with my earlier post should allow a user that does have these complicated scenarios to import VS projects for a build.

This function uses a system class to import the VS project.  The AX SysAutoRun functionality allows users to call a static method of a class in AX.  The AX system class SysTreeNodeVSProject has a static method called importProject() that takes an argument of a VS project file and imports it into AX.

Using the Import-AXVSProject function in conjunction with the Compile-AXXppNode function will allow you to import VS projects and compile them in any order that you need to.  If you have projects that are dependent on AX code to compile correctly, you can compile the AOT or specific nodes of the AOT before importing and compiling the project.  If the AX code or another VS project is dependent on the VS project, you can change that order.  These functions allow you to import and compile in a manner that gives you control over order and saves time from a full AOT compile.

The Import-AXVSProject custom PowerShell function takes between 1-8 parameters:

  • ConfigPath (Client configuration for the chosen AX environment)
  • VSProject (The VS project to import)
  • LogFile (The logfile for SysAutoRun.  Has a default value so you only need to specify if you want to change the location.)
  • Timeout (The value defaults to 90 minutes but can be overridden if desired)
  • SMTPServer (SMTP server to use to send the email)
  • MailMsg (Net.Mail.MailMessage object used to send the email)
  • AXVersion (The AX version.  It defaults to 6.)
  • VariablePath (Path to a file used to default the parameters/variables)

This function can be found in Codeplex.  The steps of this function are:

  • Load the variables if a VariablePath parameter is used
  • Get the AX environment info using Get-AXConfig
  • Set up the AutoRun xml command
  • Get the AutoRun xml using the Get-AXAutoRunXML function
  • Call the Start-AXAutoRun function to compile the node
  • Send the success/fail message

This is the last function necessary to create an automated build process.  In the coming weeks I will be cleaning up my current posts to fit with some changes I have made to the existing functions and I will post a blog about putting these functions together to allow you to automate your build.  I will also be releasing a module to Codeplex in the next month that will have all of the functions packaged up for easy deployment.

Compile-AXXppNode

07 Friday Aug 2015

Posted by John Hagler in Powershell

≈ 4 Comments

Tags

AOT, Automation, AutoRun, AX, AX 2012, Build Scripts, Compile, Dynamics AX, PowerShell

The Compile-AXXppNode function is the first of 2 functions to support more complicated VS project scenarios.  I have taken this approach from here.  I don’t personally use this approach in my build as my current environment doesn’t require it but this function along with my next post should allow a user that does have these complicated scenarios to import VS projects for a build.

This function can return the compile results in an email but it requires a code change in the SysAutoRun.execCompileApplication() class method.  When compiling everthing, the SysCompileAll::compile() class method calls the SysCompilerOutput::exportLog() class method.  This exports the log to the user’s “C:\Users\..\Microsoft\Dynamics Ax\Log\” folder.  If you want this log to be available, you need to add the SysCompilerOutput::exportLog() class method call to the node compile section of code.  I realize that this is a chicken and egg type thing as this custom code would need to be imported into the build environment before importing and compiling VS projects but it is possible to implement.

The AutoRun xml does have the ability to specify a log file as well but this log file will only show you what nodes were compiled.  There is no message regarding the results of the compile in it.  Because of this limitation, I didn’t used this log in the function.

SysAutoRunCompileLogChange

The Compile-AXXppNode custom PowerShell function takes between 2-7 parameters:

  • ConfigPath (Client configuration for the chosen AX environment)
  • Node (The AX node to compile)
  • Timeout (The value defaults to 90 minutes but can be overridden if desired)
  • SMTPServer (SMTP server to use to send the email)
  • MailMsg (Net.Mail.MailMessage object used to send the email)
  • AXVersion (The AX version.  It defaults to 6.)
  • VariablePath (Path to a file used to default the parameters/variables)

This function can be found in Codeplex.  The steps of this function are:

  • Load the variables if a VariablePath parameter is used
  • Get the AX environment info using Get-AXConfig
  • Get the Compile node AutoRun xml using the Get-AXAutoRunXML function
  • Call the Start-AXAutoRun function to compile the node
  • Send the success/fail message

As I said in the last post, I have been in contact with Martin Drab.  He is developing the DynamicsAXCommunity PowerShell module that I piggyback off of.  He has incorporated the last change that I needed for my functions to work in the latest build of the module (0.3.5).  I haven’t tested it out yet, but my functions should now work with his module with no customizations.

Follow Day 2 Day Dynamics on WordPress.com

Day 2 Day Dynamics

  • RSS - Posts
  • RSS - Comments

Follow me on Twitter

My Tweets

Recent Posts

  • Minimizing Database Calls
  • Push-AXModel custom PowerShell function
  • Clean-AXModel custom PowerShell function
  • Get-AXTFSCombinedXpo custom PowerShell Function
  • Refresh-AXAifPort custom PowerShell function

Archives

  • February 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015

John Hagler

John Hagler

John Hagler

I am the Dynamics AX Technical Architect at Dealer.com. I have been working with AX since Sep. 2006, starting with Axapta 3.0. I have worked as both a VAR and an AX customer.

View Full Profile →

Blog at WordPress.com.

  • Follow Following
    • Day 2 Day Dynamics
    • Already have a WordPress.com account? Log in now.
    • Day 2 Day Dynamics
    • Customize
    • Follow Following
    • Sign up
    • Log in
    • Report this content
    • View site in Reader
    • Manage subscriptions
    • Collapse this bar
 

Loading Comments...