Despite the fact that I built a Powershell module for maintenance tasks of AX 2009 and AX 2012 environments, I’m not much involved in d365fo.tools module. The credit goes to other people, especially Mötz Jensen.
Nevertheless I’ve recently added a small feature to Get-D365Module that you might be interested in.
Get-D365Module normally returns modules (packages) sorted by name. But when you want to compile modules, you need a different order. If you compiled a module that refers to a module that hasn’t been compiled yet, you’d likely get errors. Therefore you need to start with modules that have no such dependencies, then compile modules that depends only on already compiled modules and so on.
The new -InDependencyOrder parameter of Get-D365Module (available from version 0.6.77) will give you that. If I run it for standard modules, the list starts with ApplicationPlatform, because it has no dependencies, continues with ApplicationFoundation, which depends on ApplicationPlatform only, and so on.
What I typically want to compile are just custom modules (developed by my team or provided by ISVs as non-binary modules), not modules from Microsoft. You could, for example, maintain a list of custom modules and filter by this list, but I do it differently.
I don’t put any custom modules to PackagesLocalDirectory – I use a separate folder which contains custom modules and mere symbolic links to standard packages in PackagesLocalDirectory. When I want to get only custom modules to compile, I can use Get-D365Module –InDependencyOrder and then filter out symbolic links. For example:
$metadataDir = 'k:\Repo\Dev\Metadata' $customModuleNames = (ls $metadataDir -Directory | ? LinkType -ne SymbolicLink).Name Get-D365Module -InDependencyOrder -ExcludeBinaryModules -PackageDirectory $metadataDir ` | ? -Property ModuleName -In $customModuleNames