I have tested the scenario and replicated the behavior using your sent (over email) test project. Even though I cannot say why this happens, this seems to be very project specific as I cannot replicate it in a new project with same configuration.
Recently Microsoft announced that starting July 28, 2025 their Trusted Signing Tooling version 1.0.52 (and older) will no longer be supported.
Starting with next version of Advanced Installer (v22.8) our Trusted Signing support will be fully compliant with the newer versions of Trusted Signing ...
I am following up here as agreed with the workaround solution we found for this issue.
After further troubleshooting on this we were unable to find out the root cause of the file redirection issue. There seems to be a crash generated by the Microsoft's Package Support Framework SDK ...
I have tested your setup project and replicated the issue. It seems the behavior is caused by the fact I forgot to document one last step you need to configure. I apologize for this.
The last step you need to configure is in "Table Editor" view. In ...
The fontSetup.msi file seems to be configured fine.
Can you please send me the .AIP (setup project) file of your main setup by email at support at advancedinstaller dot com ? The one that installs the "fontSetup.msi" file using a custom action as exposed in steps 2 to 7.
Can you please give us more details about the exact error you are facing with? Do you get any specific error when running your DevOps pipeline? If so, could you share with us the Advanced Installer Build Task log?
Basically if you want our Advanced Installer Build ...
A possible solution for you will be to build the setup project on the fly. For instance you can try to trigger an installer build from your web site after the customer fill in his data and then upload the built installer to your customer.
In your setup project you can go to "Properties" page ...
You should be able to write in the 64-bit section of the registry as long as your PowerShell custom action is configured to use the "x64" platform. I have just tested this and successfully ran and created the 64-bit registry.
screen1.png
Can you try to use the New-ItemProperty cmdlet and ...
This approach does not work because during a deferred custom action you cannot set an installer property. Only from an immediate action you can set an installer property.
The correct approach would be to try writing your value in a temp resource (e.g. registry, file) and then accessing it from ...