Error opening file ".SWIDTAG"

[kietvta]

Dear all

How you ever seen this error message when installing setup package as image below?

Thanks in advanced.

[Dan]

Hello,

I'm not sure why you encountered this behavior.
In order to have a better view about this, can you please send us the .AIP (project file) and a verbose log of the installation process?

Here's the "Create a log" article:
http://www.advancedinstaller.com/user-guide/qa-log.html

Best regards,
Dan

[kietvta]

Dear Dan

I enclose here set log file and AI project.
Would you inspect the error please.

Thank you very much.

[Daniel]

Hello,

Please accept our apologies for the delayed answer. We have been quite busy lately.

It seems the related error is caused by the "Software Identification" option in conjunction with the per-user install type. When the "Software Identification" option is enabled the product info details will be written in a few XML files at install time. These XML files are created under "Common Application Data" folder (i.e. C:\ProgramData)\) which is only a per-machine location. Thus the current per-user install type won't have access to this location, therefore the software identification XML file cannot be created. Currently, this is an Advanced Installer limitation. We will try to add an improvement in the future, thank you for bringing this to our attention. We will update this thread as soon as a resolution is found.

Until then, as a workaround, please go to "Product Details" page -> "Software Identification" tab and uncheck the "Enable Software Identification Tag" option.

All the best,
Daniel

[Daniel]

Hello,

We have recently tested this scenario (using the Software Identification option) with a per-user only installation type and it seems everything is working as expected.

When you have time, if you are interested to test this out you could rebuild your setup project using AI 15.8 version and let us know if the issue still replicates.

All the best,
Daniel

[aweber]

We are seeing this with a per-user install (upgrade in this case). MSI is built using 16.3.

Very possible the user does not have write-access to the per-machine location - we are trying to investigate.

Is it not possible, when the install is Per User, to write these files to a per-user folder? That would make sense, wouldn't it? (We actually use per-user installations due to security restrictions on some Windows PCs.)

EDIT: During an upgrade attempt (using the AdvancedInstaller update exe), we got this same error for a user that actually has local admin rights. The folder inside \ProgramData for our app already existed...and that modify date was actually updated to "today". However, the .swidtag file inside that folder is not updated - it is the original file from the previous version's install.

Also, when it fails, the old version has already been removed...so the user is left without the application!

This is bad.

[aweber]

Can anyone from AI-team comment on this please?

It may be that the AI updater exe that gets packaged for updates has an issue with updating the swidtag file in some circumstances. I don't know how to reproduce it reliably, but it is causing major issues with our updates.

ALSO: Can someone tell me what the implications/side-effects are if we disable the Software Identification tags? Especially if they have been present in previous versions and then we remove them from an updated package? What are we "losing" by not including these tags in our software install? Are there issues if there were previously tags, but an update no longer includes them???

[Catalin]

Hello AJ,

First of all, please accept my apologies for the delayed reply.

I have tried to test this behavior, but everything worked as expected for me.

In order for me to further investigate this, could you please forward me a verbose log of the upgrade process by e-mail at support at advancedinstaller dot com?

Looking forward to hearing from you.

Best regards,
Catalin

[aweber]

Can someone tell me what the implications/side-effects are if we disable the Software Identification tags? Especially if they have been present in previous versions and then we remove them from an updated package? What are we "losing" by not including these tags in our software install? Are there issues if there were previously tags, but an update no longer includes them???

I will try and get the logs, but I have had to pause all updates because of the failures and our users no longer have an installed program due to the failures.

Can you please comment on this part of my question ASAP so we know how to resume our updates???

[Catalin]

Hello AJ,

Can someone tell me what the implications/side-effects are if we disable the Software Identification tags?

There are no side-effects if you disable the "Enable Software Identification Tag" option.

What are we "losing" by not including these tags in our software install? Are there issues if there were previously tags, but an update no longer includes them???

You will not loose anything. And no, there should not be any issues.

Hope this helps.

Best regards,
Catalin

[possumdelight]

+1. For me, this seems to happen when installing as Administrator (successfully), and then as a User (which fails) - perhaps because the SWID file already exists in the ProgramData folder. If I uninstall as Administrator, the file is removed and I am able to install as the User.

[Catalin]

Hello Charles and welcome to our forums,

From what I can see, my colleague Eusebiu has answered you over the mail.

Best regards,
Catalin