Get-D365Model and Get-D365Module are skipping directories without existing binaries

[rsteber]

Hi guys!

I noticed when creating my own PowerShell module, that uses functions from d365fo.tools, that D365 modules or models that do not (yet) have a "bin" directory are not found by the tools .

A try with the code from the DynamicsSDK script "GenerateProjFiles.ps1" shows that all module directories are recognized and used by the MetadataProvider inside that script.
I have not yet determined the exact difference.

It seems problematic to me that both functions mentioned above do not recognize, for example, "freshly" checked out modules from the repository.

Kind regards,
Roland

[rsteber]

Update:
The "bin" directory alone does not make a difference. Only if binaries are actually present, these models and modules are read by the two functions mentioned in the subject.

I use, for the moment, for my PowerShell module the MetadataProvider from the "Microsoft.Dynamics.AX.Metadata.Storage.dll".

[FH-Inway]

Seems this was a deliberate change, see #256

The difference is whether you use the Runtime or the Disk Provider as Metadata Provider.

What's your use case of listing models/modules that have not been compiled yet?

[rsteber]

I have created a set of local PowerShell tools that, among other things, can be used to compile the customer's modules (for example, the modules of the CUS layer) in the correct order.
Also .NET assemblies, for which the source code is available, can be compiled beforehand and positioned on the hard disk. Optionally, DB synchronization and report deployment can be performed for the specified modules. Even if individual modules are specified for compilation, they are compiled in the correct order based on the references.

For example, if a new module is added or a new local workspace is created, this tool would not select the modules without binaries for compilation if the information about the models and modules is obtained with Get-D365Module and Get-D365Model.

[Splaxi]

If you are up for the challenge, we can easily have multiple cmdlets - that work against the modules / models.

We can update the documentation for the current cmdlet, stating that it only supports PRE-COMPILED modules / models.

And the suggestion that you are proposing, is to read the folders - which will output all modules / models, regardless of their compilation state. This would allow you to output the modules, and use it for your own purpose.

But it seems that you have things working for you, with the custom scripts - so are there any value in the d365fo.tools for you?

Would you like to add your own scripts to d365fo.tools and share them with the community?