Tag Archives: Visual Studio

Get-AXTFSCombinedXpo custom PowerShell Function

02 Wednesday Dec 2015

Posted by in Powershell

≈ Leave a comment

Tags

, , , , , , , , ,

The Get-AXTFSCombinedXpo custom PowerShell function is used for getting code out of TFS as an .xpo.  At my current job, we sometimes have to hotfix .xpos for builds.  I know that the trend is to move away from pushing .xpos but when it comes to hotfixes for builds, .xpos are significantly faster than creating another build and pushing a model.

We have a team dedicated to unit and regression testing and we regression test every model build before it is moved to production.  When we discover issues in the model build, we hotfix the build using .xpos so we can continue regression testing.

This PowerShell function uses both tf.exe and the TFS Power Tools to export the .xpo.  To use this function, you will need to run it on a server that has Visual Studio installed and connected/synched with TFS and have the TFS Power Tools installed.  Because of these requirements I run this from either my development server or from my development build server.

You will need to add some code to your profile as we’ve done for other functions.

ProfileAdd

The tf.exe reference should already exist in your profile for the TFS sync used by the build function.  The Microsoft.TeamFoundation.PowerShell reference is for the TFS Power Tools.

The Get-AXTFSCombinedXpo custom PowerShell function takes between 1-7 parameters:

  • Version (The TFS version to retrieve)
  • DateFrom (Used to set a start datetime to look up a range)
  • DateTo (Used to set an end datetime to look up a range)
  • OutputFile (The exported .xpo file)
  • TFSCollectionUrl (The URL used to connect to TFS)
  • TFSLocation (The location in TFS to get the files from)
  • 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 TFS connection object
  • Create a temporary folder to hold the uncombined .xpos
  • Determine how to get the .xpos out of TFS based on the datetime parameters and the version
  • Loop through the files and save them as .xpos in the temporary folder location
  • Create the output file directory
  • Use CombineXPOs.exe to create the combined .xpo
  • Clean up the temporary folder and files

This function can be used to grab a single changeset, a range of changesets, a label version, or even the entire codebase.  I primarily use it to get a single changeset or a range of changesets.  Synching the TFS working folder is significantly faster than trying to grab a label version or the entire codebase with this function so I wouldn’t recommend using it for those purposes but it is able to if you want it to.

To get a range of changesets, use the date field information (datetime) of the TFS history to set the DateFrom and DateTo parameters.  Then use the latest changeset value in that range to set the Version parameter.  You can pass the DateFrom and DateTo as strings and the parameters will convert them to datetimes.  I have only tested the formatting of this using the en-us datetime format (M/d/yyyy h:mm:ss tt) so it is possible that you may run into issues if you are using another datetime format.  Please let me know if you experience any problems.

I am using this function with Visual Studio 2012, TFS 2012 and AX 2012 R2 CU7.  It has not been tested with other versions but may work with them anyway.

I am releasing this function as part of the D2DDynamics module (1.0.4) and as a standalone function at the current time.  I am determining whether or not I will remove the standalone functions that also exist in the module from Codeplex in the near future and will notify you through my blog if I do.

 

Import-AXVSProject custom PowerShell function

18 Tuesday Aug 2015

Posted by in Powershell

≈ 1 Comment

Tags

, , , , , , , , ,

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.

Start-AXMSBuildImport

23 Thursday Jul 2015

Posted by in Powershell

≈ 2 Comments

Tags

, , , , , , , , , , ,

This has been an extremely difficult blog post for me to write.  I have been struggling with it because I realized that I didn’t really understand the process that I was using to accomplish my VS project import.  I took an extra week to research it and hopefully write up something useful and I have actually discovered that my process may not work for a lot of people.

I am using the ImportVSProjects.proj with msbuild.exe that I found in the Dynamics AX Build Scripts.  This project is passed into msbuild.exe with parameters that allow it to loop through a TFS directory and import the found VS projects into Dynamics AX 2012.  I have since discovered that there can be issues with projects that have dependencies on AX objects or other VS projects.  I personally don’t work in an environment that has complex dependencies, so I’ve never run into any of these issues.  There are other solutions that involve using the autorun.xml to call SysTreeNodeVSProject::ImportProject and compile for a specific AOT node.  I will be exploring these in future posts but the current method is the one I use.

The Start-AXMSBuildImport function takes between 1-14 parameters:

  • ConfigPath (Client configuration for the chosen AX environment)
  • MSBuildPath (The folder location of msbuild.exe)
  • ImportVSProjectsFile (The ImportVSProjects.proj file to use)
  • ModelFileFolder (The TFS working directory location for the Model that has VS projects to import)
  • Layer (The layer to import the VS projects into)
  • LayerCode (The license code for development in the layer)
  • ModelName (The model to import the VS projects into)
  • BuildLogFolder (Specifies the log folder location.  Defaults to $env:TEMP.)
  • DetailedSummary (Parameter for msbuild.exe that creates a detailed summary in the log file.)
  • Verbosity (Parameter for msbuild.exe that allows you to set the level of logging)
  • Timeout (The value defaults to 30 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)
  • VariablePath (Path to a file used to default the parameters/variables)

This function and the ImportVSProjects.proj can be found in Codeplex.  The steps of this function are:

  • Load the variables if a VariablePath parameter is used
  • Build the log files
  • Set up the arguments for the msbuild.exe call
  • Call msbuild.exe to import the projects
  • Send the success/fail message

I have also been cleaning up some of my PowerShell functions in preparation for putting them into a module.  I have made slight changes for uniformity and incorporated some suggestions from other AX users.  I have also incorporated my changes in the latest version of the DynamicsAXCommunity module (0.3.4).  I also have hopes that the next version will support my module with no customizations.  I will be updating past blogs posts in the near future to support my changes.