We use git for our source code repo, and AIP to install a couple of products. Right now we are considering buying licenses for everyone on the team so everyone can do install work, but because of some bad experiences I have had working with AIP XML during merges I am thinking of recommending we switch to something else. I would prefer not to do this because we have so much time already invested in learning AIP and in the installer we have built, but I think it is going to be a nightmare with everyone on the team trying to do difficult merges.
We have an ongoing problem of horrible, ugly merges between branches with the AIP XML file. It has been an impossible task during a couple of recent merges we have had to do, and in a couple of cases I have personally had to just throw away branch work and redo it again on our main branch after a merge. It seems that the way AIP generates XML makes it very difficult to merge two branch's of AIP work. As I mentioned we use git but I think this would be a problem under other source code repos I have used such as Hg, CVS or SVN. Can anyone recommend advice on doing a successful merge? Perhaps there is a tool available to help with merging of AIP? We are already using BeyondCompare for merging which is a fantastic application that helps us merge pretty much every other file we have with ease.
TIA for any help.
Suggested Articles
Re: Git Merge Issues with AIP
Hi Joe and welcome to our forums,
Thank you for your interest in Advanced Installer.
Unfortunately the .aip files cannot be merged due to its implementation design. As you have noticed, the chances to merge it and still have Advanced Installer load the project are very small. For example we use SVN in our local system, but we never apply merges on .aip files, we choose to open the project in Advanced Installer for each change that must be done.
What you can try would be for your to add a manifest file in your directory containing the .aip file in which you add a MIME type for the .aip files to be interpreted as binary data and skipped from merging, this is supported by Git. And for any changes you need, you would open the project and apply them from Advanced Installer.
Do you have an high number of changes that occur daily for your installer projects that require merging?
Best regards,
Bogdan
Thank you for your interest in Advanced Installer.
Unfortunately the .aip files cannot be merged due to its implementation design. As you have noticed, the chances to merge it and still have Advanced Installer load the project are very small. For example we use SVN in our local system, but we never apply merges on .aip files, we choose to open the project in Advanced Installer for each change that must be done.
What you can try would be for your to add a manifest file in your directory containing the .aip file in which you add a MIME type for the .aip files to be interpreted as binary data and skipped from merging, this is supported by Git. And for any changes you need, you would open the project and apply them from Advanced Installer.
Do you have an high number of changes that occur daily for your installer projects that require merging?
Best regards,
Bogdan
Re: Git Merge Issues with AIP
Our product is fairly young and so we are adding new features on a rapid basis which often necessitate installer changes. We run into several problems merging with AIP because of this. First, we almost always have a hotfix branch running and if an installer change needs to be made on the hotfix, which while not common is not unusual, then we need to merge that back up to our main develop branch. We also work on features using the git-flow branching model so that developers can pair on a project or otherwise work in isolation on a branch until a feature is ready, at which time it is merged to the main develop branch. Our continuous integration runs installs so merging down to our develop without installer changes is kinda frowned upon in general. However, because we have had very bad luck with merging AIP we are basically doing what you mention which is to redo changes on the develop branch, which of course is not our regular work flow and can cause a lot of human error.
Re: Git Merge Issues with AIP
There would be a solution for you to be able to use the same .aip file and skip merging it using the synchronization folder support. This would work only if you would have a well defined design for the setup package, and have only the list of resources variable.
What is the the advantage of this feature is that Advanced Installer automatically includes in the the package all the new sources from the target synchronized folders. So if new resources must be included in the package, this is done automatically, without being required for you to open the project and add them explicitly.
Regards,
Bogdan
What is the the advantage of this feature is that Advanced Installer automatically includes in the the package all the new sources from the target synchronized folders. So if new resources must be included in the package, this is done automatically, without being required for you to open the project and add them explicitly.
Regards,
Bogdan
Re: Git Merge Issues with AIP
Hate to post on such an old thread - but this is really a frustrating issue that creates a lot of issues for people using Advanced Installer with larger teams of engineers. When multiple projects touch the installer and we go to merge it requires the engineers to basically redo all of their changes manually.
Is there any chance of adding a new format (.aipx maybe?) that is more source management friendly to the roadmap? This would be greatly appreciated, and I'm sure I'm not the only one who would love to see this.
Is there any chance of adding a new format (.aipx maybe?) that is more source management friendly to the roadmap? This would be greatly appreciated, and I'm sure I'm not the only one who would love to see this.
Re: Git Merge Issues with AIP
Hello,
A possible workaround for this, when you need to commit a change in the setup project, is to commit the AIP file entirely as a binary file.
Best regards,
Catalin
I can't really say whether there is a chance such new format will be added to Advanced Installer, as this is quite complicated to achieve using the XML format that the AIP files have. Also, this hasn't really been requested a lot, so that drops the priority as well.Is there any chance of adding a new format (.aipx maybe?) that is more source management friendly to the roadmap? This would be greatly appreciated, and I'm sure I'm not the only one who would love to see this.
A possible workaround for this, when you need to commit a change in the setup project, is to commit the AIP file entirely as a binary file.
Best regards,
Catalin
Re: Git Merge Issues with AIP
Hi @zedlex,
What changes did you made to they AIP file and what version of Advanced Installer are you using? In the last years we made some improvements related to merging changes in the files area, i.e. adding/removing files from the package. In such scenarios, during a diff, the changes appearing should allow you to select "use both" or the equivalent option in your diff tool.
If there were changes in other areas, like Custom Actions, Prerequisites or Dialogs Editor, please share as many details as you can and we'll evaluate them for further improvements.
Best regards,
Bogdan
What changes did you made to they AIP file and what version of Advanced Installer are you using? In the last years we made some improvements related to merging changes in the files area, i.e. adding/removing files from the package. In such scenarios, during a diff, the changes appearing should allow you to select "use both" or the equivalent option in your diff tool.
If there were changes in other areas, like Custom Actions, Prerequisites or Dialogs Editor, please share as many details as you can and we'll evaluate them for further improvements.
Best regards,
Bogdan
Re: Git Merge Issues with AIP
Hello,
We also are using git and branching for our 3 main projects, using c# and other solutions.
We have a few key notes:
1- I'm mainly the person responsible for the installers, so I'm mainly modifying one branch at a time, and merging the changes after I'm done, as I'm the last link in the dev / merge process. We always make sure the "master" branch has been merged into the branch before making any setup changes, to avoid conflicts as much as possible. Or we avoid modifications in the main branch if we have a pending merge from a branch.
2- Reduced Components: Our projects produces zipped files (containing all the dll's and ressources), except the executable files. The advanced installer project unzips the file in the target folder, and installs the exe file there, register the services, etc. This means that we don't have to modify the setup much. This is doable since the projects have self contained dll's in the same folder as the exe, we don't have to register dll's elsewhere or manage individual files. This also keeps our "components" count to a minimum. Before we started zipping the files, we had a single component for all the app dll's in the same folder.
3- Action Identifiers: when adding things in the setup, Advanced installer tends to auto-number the items, starting from 1, so there is a good risk to conflict there, making the project unusable. Before committing to git, I sometimes change the auto-numbers to unique identifiers: for example renaming "AI_DATA_SETTER_11" to "AI_DATA_SETTER_SQLTEST" or "AI_DATA_SETTER_AUTH" everywhere in the aip project file, to ensure uniqueness. This can be done before commit, also while merging. It would be nice to be able to rename those Properties directly from Advanced Installer UI, maybe in an "advanced mode".
4- Action Sequences: This one is very hard to avoid conflicts. Advanced installers auto-numbers the sequences, and I manually check the ordering before the final commit.
5- Merge no commit: I use the no-commit option when doing merges, so I can review manually the project and even open it in AI to make sure it's valid.
6- First Name right: Try naming your items correctly on the first time, as ID's are named from your initial creation. Renaming items doesn't rename the ID's so you can quickly get confused or conflicts when everything has the defaults names.
We also have forks of our main projects, customized per client. We have integrated support for customization in the main projects, so we can fork without major changes to the setup. Properties are used for custom text, and we only add more components and files on rare occasions.
When merging, as long as the entries have unique names and falls under the correct "Component" xml block, you should be ok. Ordering of nodes are not important, but you may see AI auto-reordering the items, which we try to avoid in dev branches, committing only additions.
So my suggestions for AI, would be to be able to rename internal objects ID's (nodes id's in xml updates, data setters in actions, directory id's, services id's, expand archive id's, etc) or to name them using a short guid string.
Hope this helps!
We also are using git and branching for our 3 main projects, using c# and other solutions.
We have a few key notes:
1- I'm mainly the person responsible for the installers, so I'm mainly modifying one branch at a time, and merging the changes after I'm done, as I'm the last link in the dev / merge process. We always make sure the "master" branch has been merged into the branch before making any setup changes, to avoid conflicts as much as possible. Or we avoid modifications in the main branch if we have a pending merge from a branch.
2- Reduced Components: Our projects produces zipped files (containing all the dll's and ressources), except the executable files. The advanced installer project unzips the file in the target folder, and installs the exe file there, register the services, etc. This means that we don't have to modify the setup much. This is doable since the projects have self contained dll's in the same folder as the exe, we don't have to register dll's elsewhere or manage individual files. This also keeps our "components" count to a minimum. Before we started zipping the files, we had a single component for all the app dll's in the same folder.
3- Action Identifiers: when adding things in the setup, Advanced installer tends to auto-number the items, starting from 1, so there is a good risk to conflict there, making the project unusable. Before committing to git, I sometimes change the auto-numbers to unique identifiers: for example renaming "AI_DATA_SETTER_11" to "AI_DATA_SETTER_SQLTEST" or "AI_DATA_SETTER_AUTH" everywhere in the aip project file, to ensure uniqueness. This can be done before commit, also while merging. It would be nice to be able to rename those Properties directly from Advanced Installer UI, maybe in an "advanced mode".
4- Action Sequences: This one is very hard to avoid conflicts. Advanced installers auto-numbers the sequences, and I manually check the ordering before the final commit.
5- Merge no commit: I use the no-commit option when doing merges, so I can review manually the project and even open it in AI to make sure it's valid.
6- First Name right: Try naming your items correctly on the first time, as ID's are named from your initial creation. Renaming items doesn't rename the ID's so you can quickly get confused or conflicts when everything has the defaults names.
We also have forks of our main projects, customized per client. We have integrated support for customization in the main projects, so we can fork without major changes to the setup. Properties are used for custom text, and we only add more components and files on rare occasions.
When merging, as long as the entries have unique names and falls under the correct "Component" xml block, you should be ok. Ordering of nodes are not important, but you may see AI auto-reordering the items, which we try to avoid in dev branches, committing only additions.
So my suggestions for AI, would be to be able to rename internal objects ID's (nodes id's in xml updates, data setters in actions, directory id's, services id's, expand archive id's, etc) or to name them using a short guid string.
Hope this helps!
Re: Git Merge Issues with AIP
Hello,
Thank you very much for sharing this with us - I am sure this will come in handy for furher users wanting to achieve a similar outcome.
Regarding the feedback, I will forward it further to my manager.
Best regards,
Catalin
Thank you very much for sharing this with us - I am sure this will come in handy for furher users wanting to achieve a similar outcome.
Regarding the feedback, I will forward it further to my manager.
Best regards,
Catalin