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.
Issue
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.
Root Cause
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.
Microsoft Response
This issue actually caused enough of a stir that Microsoft put out a short issue resolution page on LCS:
Same issue is happening in 10.0.32 preview. Also, I would like to point out that not only do you need to remove the orphaned records, but if you have a gap in the numbers ex. .1.netmodule, .3.netmodule it will still error for .2.netmodule.
Great point Sam!
Unfortunately some ISV does not do this and it takes weeks to month with no correct Deployable Package.
On the other side the communication for this was really bad in my opinion as there were no information before the change.
Perhaps I have a solution if net modules are missing like 0,1,…,6. In those cases there are often only the xml of the net modules. So my solution approach is to check if the references in the xml files are existing in the files with a .Netmodule.
So in the example above let’s say 2 till 5 are only existing with .Xml files. Copy the missing references to the netmodule6.xml, delete files 2-5 and rename netmodule6.xml and netmodule6.netmodule to the following:
netmodule2.xml
netmodule2.netmodule
Never tried it so it is only a solution idea. Better way is probably to annoy the ISV partner to ship a correct Deployable Package. In most case the ISV partner gets license money so he should also supply a correct package.
Thanks, Tobias, for your info. We were unable to able to create package on our 10.0.31 VM. I came across your comment and saw netmodules missing. And I followed your approach for copying xml and netmodules files, and it worked as expected.
We are also facing the same issue so we tried cleaning the sources using the DevOps pipeline but no luck.
We identified that unnecessary .netmodule files exist in the system from the previous deployments of ISV where we have to remove them manually from the code base which resolved the issue.