🧩 d365fo.tools goes Power Platform

[FH-Inway]

Microsoft is currently transitioning hosting of D365FO environments from LCS to the Power Platform. This introduces a lot of changes that also impact d365fo.tools. If you are new to the topic or need a refresher, take a look at the following resources:

• Unified admin experience
• Unified development experience
• One Dynamics One Platform TechTalk Series
• Blog with roadmap by @AurelienClere-365

Inspired by #854 and the fact that I had opportunity to play with the unified experiences, I wanted to start this discussion on how we could get d365fo.tools ready for the Power Platform.

[FH-Inway]

At the moment, I just have a collection of random thoughts and ideas, in no particular order:

• (parts of) d365fo.tools can be used with unified environments. I was for example able to get Get-D365Model and Invoke-D365ModuleCompile to work on a Windows 11 vm with the development tools installed. See d365fo.tools-unified.ps1 for how this looks like.
• cmdlets similar to Get-D365Model (i.e. ones with -BinDir or other Dir parameters) can be used as is (though a bit painful)
  • there are however exceptions, e.g. Invoke-D365BestPractice does not work, because there is no parameter to provide a directory for the -packagesroot parameter of xppbp.exe
• other cmdlets do not apply to the Power Platform, e.g. all the LCS cmdlets.
• first step is probably to give d365fo.tools the capability to recognize if it is running on an environment with the unified development experience; the place to add this is probably in variables.ps1; needs some research to determine a good criteria
• next step would be some internal functions to determine the current configuration and set some variables based on that
• open questions
  • in what order should cmdlets be made Power Platform ready? what are the most important ones? we currently have more than 200 cmdlets
  • how to handle cmdlets that cannot be made ready?
  • how can the community help with this?

Looking forward to getting some feedback on this.

[AurelienClere-365]

Happy to help if needed 😉 - especially on the PAC CLI for F&O cmdlets

[FH-Inway]

On the topic of determining if d365fo.tools is being executed on a UDE: Seems that information of the active UDE configuration is stored in registry values at Computer\HKEY_CURRENT_USER\Software\Microsoft\Dynamics\AX7\Development\Configurations.

On local VHD and CHE environments, there is also a registry value CompatibilityMode set to 1 in Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dynamics\AX\Development. According to @Pankaj-Thakur from Microsoft, this is a criteria for non-UDE environments (see https://www.yammer.com/dynamicsaxfeedbackprograms/threads/2817784834039808).

A related discussion is also happening here: ameyer505/D365FOAdminToolkit#45 (comment)

UDE registry

CHE registry

[FH-Inway]

Based on the registry values, I started #868 to use those values for the d365fo.tools.

[FH-Inway]

I've been playing around with GitHub projects and the GitHub CLI / GraphQL API (see GitHub-Project-Manager.ps1).

The idea is to have a project with one item per cmdlet of d365fo.tools. The project can then be used to organize and track the progress in making the module ready for a unified world. First draft of the project: https://github.com/users/FH-Inway/projects/2

A PoC script exists to populate the project with the cmdlet items. In the project draft, items 8 through 12 have been created with the script.

@Splaxi I made you a maintainer of the project draft, if you want to play around with it.