InstallAware

I'm using InstallAware Multi-Platform for Windows. My installer works fine most of the time during installation, but occasionally I get this error:
'The system cannot find the file specified.'
Because of this, the installation fails. It's hard to reproduce since the issue occurs randomly.

All the required files are included in the installer, so I don't understand why this error happens.
I don't think an antivirus is causing it either, since the error doesn't occur consistently.

Could you help identify possible reasons for this issue?
[img][/img]

I have attached a sample project where the issue is occurring—please take a look, Also attached single exc.
Also, inside InstallAware, from the "From File" section using the path $TARGETDIR$, please attach a sample file as well.

Please add all required files to the project and try uploading again.

You can reference the project folder in your build script using the #PROJDIR# pre-defined compiler variable (https://www.installaware.com/mh52/desktop/predefinedcompilervariables.htm).

I already mentioned that you can attach any file, but for your convenience, I have also attached my file.
Also, please select the install location as C:\Program Files (x86)—this makes it easier to reproduce the issue.

Still doesn't build, same error:


Please ensure you've made any applicable changes to your project before sending.

Additionally, I recommend you test it yourself before sending on a clean machine, to guarantee it works (and as the case may be, fails) as you intended.

This time, I have already checked it on another machine. It was my mistake — I sent the previous file again due to the same file name.
Please find the new file attached.


But in case the build fails again, please add this line to your code.
,
As File i used logooo (1).png already inside project file.

I think you have some bugs in your setup flow.

The first time I ran it, it requested elevation (although I was trying to install into a non-protected folder).

I cancelled out of it, since no elevation ought to be required for that folder.

Then running setup again, it ran without asking anything and completed immediately.

Then I also was able to uninstall it successfully.

I wasn't able to reproduce your issue.

Please note that I ran your setup inside the IDE.

I have fixed all the issues. Please note that the issue does not reproduce in debug mode or uncompressed build. It only reproduces in the compressed mode build.
If you first install using the uncompressed mode, especially in C:\Program Files (x86), and then uninstall it, the installed file is not deleted because I haven't implemented uninstall with uac logic. Please manually delete the file from that location. If the installed file remains, and you later install using the compressed build, the issue does not reproduce.

However, if you install using the compressed build directly in C:\Program Files (x86), the issue does reproduce.

I think you still have some important issues you need to resolve.

For example, if you install as admin, but haven't implemented escalation during uninstall to admin; then it is only natural that the uninstallation and/or repair would fail with messages (similar) to the one you have shared - seeing as the non-elevated uninstaller would not have rights to access files created by the elevated installer.

You're creating a lot of artificial issues by not finishing the implementations of ideas you have undertaken.

As it stands, I don't even know when the error screenshot you shared is occurring, and am speculating about causes and conditions.

Please fix your implementations and test them thoroughly in all scenarios to avoid going around in circles with avoidable issues.

A tip that might be helpful in your scenario is using persistent variables to store the elevation state of setup, so when it has been launched in maintenance mode, you can elevate if necessary (thus facilitating elevated uninstalls).

Our philosophy here is to elevate at start or to never elevate, as we find elevation prompts served at the 11th hour distracting and bad user experience - especially as we strive to build installs which can complete unattended (that includes resuming from interruptions such as broken server downloads unattended) and don't require constant babysitting with never ending new prompts for user interaction that have been delayed for no good reason.

Dear John,

I have implemented all the logic in my main project. The code I provided is just a sample to reproduce the issue.

You are right — it's best to either always elevate at the start or never elevate at all. However, we have a different plan, which is why we are making UAC elevation optional.

Please use the build file I shared earlier. As I mentioned, the issue can be reproduced easily with it.

Build the shared project in compressed mode and set the destination to:
C:\Program Files (x86)

Steps to Reproduce:
1) Open my InstallAware support project.
2) If the build fails due to missing files (even though I’ve already added them):
3) Go to the Visual tab.
4) Inside Setup Architecture, select Files and insert any file into the $TARGETDIR$ folder.
5) Go to Batch Build.
6) Select Compressed Single File – Monolithic.
7) Build the project and run the generated .exe.
During installation, set the destination location to: C:\Program Files (x86).
9) Allow the UAC elevation. During installation, the error message will appear.

I have also provided my .exe inside the release/single folder. Just run that.

So based on your issue description, my hunch is that you're not waiting for the program you launched to complete execution.

Indeed, the Wait For Program to Finish check-box is unselected in the Run Program As command editor.

So the single file setup's self-extractor enters cleanup (and removes files you need to complete the installation) immediately after your elevated instance has started running.

Alternately, checking the pre-defined script variables (listed at https://www.installaware.com/mh52/desktop/predefinedvariables.htm), you could launch the self-extractor itself directly by using $SFXPATH$\$SFXFILE$ instead of $EXEFILE$ - thus sidestepping the cleanup issue; but this would incur a second (and redundant) self-extraction penalty.

So you probably just want to check the box in question.

That works, but the program displays both the previous dialog and the elevated dialog, causing two dialogs to appear.
This behavior negatively impacts the user experience due to the duplication.

So my idea was to save the user’s data before elevation and then pass it to the elevated installer.
However, due to the current issue, this is not working as expected.

Did you try using Hide Dialog?