If you are partner, ISV, or anyone delivering custom code to end users in D365FO, there is a change in 10.0.31 that you need to know about.
If you have a customer that upgrades to 10.0.31 and the next time they try to check in a deployable package to their source control build pipeline and they get an error similar to ‘Netmodule file missing: Dynamics.AX.<module>.<number>.netmodule’ like the one below:
And you are confused because the same deployable package was working in earlier versions of D365FO, I did some digging to find out why this was happening!
In 10.0.31, Microsoft added some additional logic to the CreatePackage.psm1 file (located in your AosService\PackagesLocalDirectory\bin folder), as the screenshot below is showing the difference in the files between a 10.0.30 version of the file and a 10.0.31 version:
This logic is basically checking for ‘orphaned’ netmodule files within your solution.
A netmodule file is ‘orphaned’ if a netmodule type file does not have a corresponding netmodule base file. For example, in the screenshot below we can see that we have a base netmodule file of Dynamics.AX.<module>.0.netmodule (green box) file but looking through the other netmodule types we can see that there is a Dynamics.AX.<module>.Queries.1.netmodule file (red box).
In this case the Dynamics.AX.<module>.Queries.1.netmodule file is ‘orphaned’ as there is no corresponding Dynamics.AX.<module>.1.netmodule file and will generate the error above.
As someone pointed out in the comments, another scenario is if you have gaps in the netmodule file numbers, for example if you have a Dynamics.AX.<module>.1.netmodule file and a Dynamics.AX.<module>.3.netmodule (skipping 2) that would also cause the error.
So how does something like this happen? This this somewhat tough as there are a couple contributing factors to this:
- The process of installing a new deployable package is additive which means that if the file existed previously but doesn’t anymore, it does not get removed from the bin folder
- This can potentially happen if a customer checks in files from the bin folder of the solution
- An ISV has building the solution from Visual Studio instead of a build server
- Potentially other scenarios, if you know of one please add it to the comments
Fixing the Issue
In my particular case, the issue resided not within the deployable package itself but in the build server of the customer having additional netmodule files within the bin directory. Once those were removed the customer was able to successfully execute the build pipeline.
Others have said that deleting the entire bin folder on the build server for the affected module and performing a full build again is another option.
If there are other solutions others have used for this please feel free to leave a comment below.
This issue actually caused enough of a stir that Microsoft put out a short issue resolution page on LCS: