I started investigating this when I noticed my msi package created with Advanced Installer 1.3 wouldn't install properly to an alternate target directory.
For example, say my product name was Tools, and my application folder was configured as [WindowsVolume]\[ProductName]. Which means my default target dir is C:\Tools. I noticed that when I changed the target dir to C:\Foo, I would end up with two folders under C:\ - Tools and Foo. After some tedious troubleshooting, I figure out why changing the target dir resulted in the two folders being created instead of one.
If a subfolder in your package's directory structure has an all-numeric name, like "2000" - you'll get the above symptom. Advanced Installer will only give an error if you try to add a top level folder that has an all numeric name. If a subfolder has an all-numberic name, it'll add it, but you'll see the weirdness above.
Steps to repro:
1. Create the folder C:\Test. Under C:\Test, create a folder named 1 (or 7, or 42, or 2003, or any name that consists only of numbers).
2. Create a text file under C:\Test\1 (without it, you'll get the error below when performing Step 3. IMHO this is a non-helpful error, but that is another issue.
Exception - A row with this key [id_] was already registered in the table.
3. Within Advanced Installer, in the left pane select Files and Folders, right-click Application Folder in the right pane, select Add Folder, and select C:\Test.
4. Build and Run the package, making sure to change the installation folder to something other than the default. Complete the install.
5. Notice that the installation folder you selected was ignored, and the default target dir was used.
6. Uninstall the package, go back into Advanced Installer and edit it.
7. Delete the "1" folder under Application Folder.
8. On your hard disk, rename C:\Test\1 to C:\Test\1a
9. Right-click Application Folder, select Add Folder, select C:\Test.
10. Build and Run the package, again specifying a different target dir than the default. Complete the install.
11. Notice it used your custom target dir and didn't revert to using the default.
The symptom I described at the beginning of this post is slightly different than the problem shown in the repro - but I'm sure they are caused by the same bug in how all-numeric folder names are handled.
Thanks,
Craig