Hi,
I would like to get a clarification on what I consider a breaking change in APPDIR synchronization between older and newer AI versions. We have many installer projects created in 19.2 with a certain synchronization setup. In order to avoid merge conflicts we use the sync option to not store files in the installer project. With one exception, the main executable which is required for Windows service registration. In 19.2 I achieve this by leaving only the main executable in the synced folder, turning on the sync in the AI project, having that single file loaded, and subsequently changing the sync settings to not save files in the project. The main executable file stays in the project. I can use it to create a Windows service and possibly more. If another dev needs to adjust the project, they can open it, do the changes and close it with no issues.
However, this stopped working at some point. We try to use the latest AI version and now when I open such a project in 21.7.1 or 22.0, it shows this in the Output panel.
- Skipped synchronization of APPDIR with <some path> because of Do not save files in project option.
- The following service - install operations: <service name> were deleted because their file APPDIR\<main executable>.exe was deleted.
This happens even if the main executable exists in the synced folder. Now if I do changes to this project and save it, I loose the Windows service registration. There's no way to make it work except fixing it in the diff tool before committing.
Is this intentional change in the behavior? If not, it's a bug. If yes, what are my options to achieve this behavior? I do not wish to have bloated AIP files with hundreds of synced files.
Actually, we are building the installers using the latest AI in our CI pipeline anyway. But from a command line. Funnily enough, there are the same output messages in the build log but the final installer turns out just fine because the main executable really exists in the synced folder.
Suggested Articles
Re: APPDIR sync behavior breaking change between 19.2 and 21+
Hello,
If possible, could you please forward me a step-by-step test case that would help me reproduce this on my end so I can further investigate this behavior?
The scenario is quite clear for me, but I wasn't able to reproduce this on my end.
Best regards,
Catalin
If possible, could you please forward me a step-by-step test case that would help me reproduce this on my end so I can further investigate this behavior?
The scenario is quite clear for me, but I wasn't able to reproduce this on my end.
Best regards,
Catalin
Re: APPDIR sync behavior breaking change between 19.2 and 21+
It's really easy, there you go.
1. Use 19.2 to create a project from a professional template.
2. Prepare a folder with a single executable, doesn't have to be a real Windows service.
3. In your project turn on APPDIR sync on the above folder. The executable will load into the project.
4. Now select the sync setting to not store synced files in the project. The already loaded executable should stay there without you doing anything.
5. Go to Services and add a new service for this executable. No need to change any settings.
6. Save and close the project. You can easily verify that the executable is used for a service registration from a notepad looking up MsiServInstComponent.
7. Now open the project in any newer version like 22.0 (that's what I used for this demo).
8. Do any change. You can simply just raise the version or change the product name, it doesn't matter.
9. Save the project.
10. Since you opened the project in a new major version a backup of the old project has been created automatically by AI.
11. You can easily verify in a notepad that MsiServInstComponent section is now missing as well as other project rows related to the executable file itself.
12. There you have it. The executable in your sync folder physically still exists, you didn't do any changes to the service registration and you still lost it juts because the project was upgraded to a newer AI version.
1. Use 19.2 to create a project from a professional template.
2. Prepare a folder with a single executable, doesn't have to be a real Windows service.
3. In your project turn on APPDIR sync on the above folder. The executable will load into the project.
4. Now select the sync setting to not store synced files in the project. The already loaded executable should stay there without you doing anything.
5. Go to Services and add a new service for this executable. No need to change any settings.
6. Save and close the project. You can easily verify that the executable is used for a service registration from a notepad looking up MsiServInstComponent.
7. Now open the project in any newer version like 22.0 (that's what I used for this demo).
8. Do any change. You can simply just raise the version or change the product name, it doesn't matter.
9. Save the project.
10. Since you opened the project in a new major version a backup of the old project has been created automatically by AI.
11. You can easily verify in a notepad that MsiServInstComponent section is now missing as well as other project rows related to the executable file itself.
12. There you have it. The executable in your sync folder physically still exists, you didn't do any changes to the service registration and you still lost it juts because the project was upgraded to a newer AI version.
Re: APPDIR sync behavior breaking change between 19.2 and 21+
Hello,
Thank you very much for providing the test case for this.
Please note, however, that this is the correct behavior that we are seeing here.
In the past, there was a bug regarding the "Do not save files in project" option. When that option is checked, the files should be removed from the project.
This issue has been fixed in version 21.5 of Advanced Installer - the latest version of Advanced Installer having the correct behavior.
In our case, when we open the project in version 22.1, the files are removed as expected and the service as well:
Hope this helps!
Best regards,
Catalin
Thank you very much for providing the test case for this.
Please note, however, that this is the correct behavior that we are seeing here.
In the past, there was a bug regarding the "Do not save files in project" option. When that option is checked, the files should be removed from the project.
This issue has been fixed in version 21.5 of Advanced Installer - the latest version of Advanced Installer having the correct behavior.
In our case, when we open the project in version 22.1, the files are removed as expected and the service as well:
- Screenshot_202.png (106.51 KiB) Viewed 4109 times
Best regards,
Catalin
Re: APPDIR sync behavior breaking change between 19.2 and 21+
Right, I can see how this is also considered the correct behavior. Do you then have a suggestion how to go about what I'm trying to achieve?
1) I want to use synchronization so that we don't have to think about adding new assemblies/resources manually into installer projects. We never build installers locally and trust our CI to produce correct results.
2) I need to register a service to a selected binary.
3) I really want to avoid crazy merge conflicts when someone opens an installer project to do a minor change (app icon, custom action) while having a different structure of the synchronized folder (devs commonly adjust their local bin folders to suit their needs and I cannot add sync filter to cover all those possible scenarios).
1) I want to use synchronization so that we don't have to think about adding new assemblies/resources manually into installer projects. We never build installers locally and trust our CI to produce correct results.
2) I need to register a service to a selected binary.
3) I really want to avoid crazy merge conflicts when someone opens an installer project to do a minor change (app icon, custom action) while having a different structure of the synchronized folder (devs commonly adjust their local bin folders to suit their needs and I cannot add sync filter to cover all those possible scenarios).
Re: APPDIR sync behavior breaking change between 19.2 and 21+
Hello,
Although I definitely understand this scenario, especially step 3, I'm afraid that there might not be something we could do here.
If the developers only look for a small change and not actually building the project (e.g. changing the icon and just saving the project, without building it), then the conflicts arose by the fact that the devs do not have the folders on their machines could be avoided.
Best regards,
Catalin
Although I definitely understand this scenario, especially step 3, I'm afraid that there might not be something we could do here.
If the developers only look for a small change and not actually building the project (e.g. changing the icon and just saving the project, without building it), then the conflicts arose by the fact that the devs do not have the folders on their machines could be avoided.
Best regards,
Catalin