During the #MSDyn365FO upgrade code cleanup exercise for Best Practice errors one of our forms got corrupted. Compilation has caused a crash, and when I tried to reopen it then it went in an endless compile loop. I had to find a way to change AOT objects without AX client.
This could be achieved by various different solutions. One option is using the SysStartupCmd framework to import a corrected XPO with the AOTimportFile startup command. Also you could try removing the objects from the ModelElement and ModelElementData tables within the AX2012_model ModelStore DB. Another solution is to go around using the client.
I went with the last option, and used a client-less approach via talking directly to the Application Object Server through the Business Connector interface. Here is a simple PowerShell script I have implemented that uses reflection for the AOT elements, where I could access a SysTreeNode object and then delete it:
# Instantiate Business Connector proxy object and sign on
Add-Type -Path "C:\Program Files\Microsoft Dynamics AX\60\BusinessConnector\Bin\Microsoft.Dynamics.BusinessConnectorNet.dll"
$ax = new-object Microsoft.Dynamics.BusinessConnectorNet.Axapta
$ax.logon('','','','','','')
# List commands
$ax | Get-Member
# Get the incorrect form object and delete the treenode
$node = $ax.CallStaticClassMethod('SysTreeNode', 'newTreeNodePath', '\Forms\CCMOrderPadActivityMK2')
$node.Call('name')
$node.Call('delete')
This is how you could change AOT objects without AX client in a fast, safe and easy way. BC is still a very powerful way of running code on-the-fly. A similar approach was applied when we wanted to validate if AIF ports were up and running on our AOS instances earlier.