Circular Reference issue

(0) Share

Report

Posted on by ford_sopris

1,229

Good day everyone. I have a bit of an issue. I am going on over 2 weeks with MS Support and have not yet found a solution. The issue has to do with pushing a deployable package to our Tier 1 (or Tier 2) testing environment using LCS to initiate the push. On step 7, we get a "circular reference" failure. We were able to push a package successfully that was built on 1/2/2020.

This does NOT show up when doing a full build on the developer workstation NOR does the automated DevOps build (on a build server) fail. The automated build is successful and a deployable package is created.

I am able to download this "bad" deployable package to my VHD type developer workstation (that is freshly deployed) and use the axupdateinstaller.exe command line to push the package without issue.

For another test -- I downloaded the metadata folder to a fresh VHD VM, compiled the 3 custom packages (I still call them models) and used Visual Studio to create a deployable package. I then uploaded this package to LCS and pushed it to our Tier 1 (and Tier 2) environments using LCS SUCCESSFULLY.

This is the same exact code.

We only have 3 custom models -- SSYImports, SSY_Main, and SSY_Integration, I have attached the 3 custom descriptor.xml. Obviously, we cannot make changes to the stock MS descriptors (just to be sure, I searched all of them for any references to the custom models using Notepad++ and nothing was found). Besides stock MS package references, here are what the 3 custom descriptor files have:

SSY_Integration -- only references SSY_Main

SSY_Main -- does NOT contain any references to the other custom models (only stock MS).

SSYImports -- only references SSY_Main

There are only 4 changesets that have been checked into DevOps since then and I am in the process of rolling each one out individually, creating a package, and pushing it to see if I can identify if it was specific to a changeset but that will take some time and any suggestions in the meantime would be greatly appreciated!

SSY_5F00_Main.xml SSY_5F00_Integration.xml

ssyImports.xml

I have the same question (0)

All responses (10)

Answers (1)

Sergei Minozhenko 23,093 on at

Like (0)

Report

Hi,

Just for information, which PU are you on?

Was this reply helpful? Yes No
nmaenpaa 101,160 Moderator on at

Like (0)

Report

Since you can deploy the package succesfully in a fresh devbox, the issue could related to something that is not in this deployable package, but exists in your sandbox system. Please check one more time if you have other custom models/packages in that system.

Could you also share the detailed error message(s) from the deployment log? Thanks!

Also, are all the systems where you deploy this package having the same Microsoft D365 version?

Was this reply helpful? Yes No
ford_sopris 1,229 on at

Like (0)

Report

All the servers are on 10.0.8 Update 32. We had failures on both a Tier 1 system that we only push deployable packages to as well as a Tier 2 UAT system. On the Tier 1 system I did confirm it only had the 3 custom model folders in the PackagesLocalDirectory and no extras. As part of my testing, I removed the 3 custom folders prior to deploying the package. Still the same error. I am in the process of spinning up another Tier1 VM from scratch and will attempt to push the package to it. That should answer the question about "somethign that is not in the deployable package but exists in your sandbox system".

Here is the error. I also checked the AosService-Update_2020XXX.log and it basically has the same error:

The step started Error during AOS update: Circular dependency detected 'dynamicsax-ssyimports 7.0.5493.35497 => dynamicsax-applicationcommon 10.0.319.10005 => dynamicsax-framework-staticmetadata 7.0.5493.35497 => dynamicsax-applicationfoundation 7.0.5493.35497 => dynamicsax-applicationplatform 7.0.5493.35497 => dynamicsax-applicationsuite 10.0.319.10005 => dynamicsax-calendar 10.0.319.10005 => dynamicsax-currency 10.0.319.10005 => dynamicsax-dimensions 10.0.319.10005 => dynamicsax-directory 10.0.319.10005 => dynamicsax-electronicreporting 10.0.319.10005 => dynamicsax-electronicreportingforax 10.0.319.10005 => dynamicsax-electronicreportingmapping 10.0.319.10005 => dynamicsax-electronicreportingcore 10.0.319.10005 => dynamicsax-financialreporting 10.0.319.10005 => dynamicsax-generalledger 10.0.319.10005 => dynamicsax-sourcedocumentationtypes 10.0.319.10005 => dynamicsax-sourcedocumentation 10.0.319.10005 => dynamicsax-ledger 10.0.319.10005 => dynamicsax-subledger 10.0.319.10005 => dynamicsax-unitofmeasure 10.0.319.10005 => dynamicsax-fiscalbooks 10.0.319.10005 => dynamicsax-banktypes 10.0.319.10005 => dynamicsax-tax 10.0.319.10005 => dynamicsax-policy 10.0.319.10005 => dynamicsax-taxengine 10.0.319.10005 => dynamicsax-electronicreportingdotnetutils 10.0.319.10005 => dynamicsax-electronicreportingbusinessdoc 10.0.319.10005 => dynamicsax-businessprocess 10.0.319.10005 => dynamicsax-casemanagement 10.0.319.10005 => dynamicsax-contactperson 10.0.319.10005 => dynamicsax-datasharing 7.0.5493.35497 => dynamicsax-financeinsightscontracts 10.0.319.10005 => dynamicsax-measurement 10.0.319.10005 => dynamicsax-personnel 10.0.319.10005 => dynamicsax-personnelcore 10.0.319.10005 => dynamicsax-personnelmanagement 10.0.319.10005 => dynamicsax-processautomation 10.0.319.10005 => dynamicsax-project 10.0.319.10005 => dynamicsax-retail 10.0.319.10005 => dynamicsax-projectmobile 10.0.319.10005 => dynamicsax-ssy_main 7.0.5179.35390 => dynamicsax-ssyimports 7.0.5493.35497'. [Log: C:\DynamicsAX\RunbookExecution-ExecuteParallelRunbook-ad4ac802-3136-4052-9c20-c05dd9241330_I0_R0\output\Step8\AosService-Update_20200228151516.log] The step failed

Was this reply helpful? Yes No
Sergei Minozhenko 23,093 on at

Like (0)

Report

Hi,

I believe you haven't done any changes in ProjectMobile descriptor.

Also, it's interesting why versions are different in dynamicsax-ssy_main 7.0.5179.35390 and dynamicsax-ssyimports 7.0.5493.35497

In my case, all custom models have the same version after build.

Was this reply helpful? Yes No
ford_sopris 1,229 on at

Like (0)

Report

No changes made to any of the stock Microsoft packages.

Was this reply helpful? Yes No
André Arnaud de Cal... 300,911 Super User 2025 Season 2 on at

Like (0)

Report

Hi Ford,

I have seen this issue before only when models did have a reference to eachother. E.g. Model1 has a reference to Model2 and Model2 to Model1. Can you also check if one of your model IDs have been used also by a (new) Microsoft model? In that case, it might also think that there might be something circular.

Was this reply helpful? Yes No
Sergei Minozhenko 23,093 on at

Like (0)

Report

Hi Ford,

Have you found any solution for this issue? Yesterday I got exactly the same issue, but in my case, I refactored 2 models and switched references vice versa. Full build was done succesfully in devbox and on build VM, but deployment failed.

I created ticket to MS support as well.

Was this reply helpful? Yes No
ford_sopris 1,229 on at

Like (1)

Report

Yes, after a lot of escalation, Microsoft found the issue. Apparently it is a bug. There was no circular reference in our descriptors. My support guy couldn't tell me exactly WHY it happened but the fix was to go into a folder in the AosService\PackagesLocalDirectory\InstallationRecords and delete the 2 custom packages that showed in the error (ssy_main and ssyimports). The folders are named like "dynamicsax-ssy_main.7.0.5493.35497". Just delete these folders and then resume the push. Fixed it!

Was this reply helpful? Yes No
Suggested answer

ford_sopris 1,229 on at

Like (0)

Report

Yes, after a lot of escalation, Microsoft found the issue. Apparently it is a bug. There was no circular reference in our descriptors. My support guy couldn't tell me exactly WHY it happened but the fix was to go into a folder in the AosService\PackagesLocalDirectory\InstallationRecords and delete the 2 custom packages that showed in the error (ssy_main and ssyimports). The folders are named like "dynamicsax-ssy_main.7.0.5493.35497". Just delete these folders and then resume the push. Fixed it!

Was this reply helpful? Yes No
Verified answer

Sergei Minozhenko 23,093 on at

Like (1)

Report

Hi Ford,

The provided solution worked in my case too. I deleted only one folder (same as the last custom package in dependency chain from the log). Also, it should be done for all AOSes.

Was this reply helpful? Yes No