Reply to Thread

Re: Renaming a previous install prior to new install

Thanks for the update!

Friedrich

Re: Renaming a previous install prior to new install

Nevermind on the last post. Found it.

Re: Renaming a previous install prior to new install

Friedrich,

What am I missing? I am trying to add one of the lines you suggested. I am trying to add this line specificly, "If %_SB_INSTALLERFLAG% Equals "1" on Position "$SB_SILENTMODEFLAG$" Then".

How do I add an if statement that uses the on option like you are using? I see the option for and, or, then, but no on. What am I missing? Thanks.

Re: Renaming a previous install prior to new install

You are very welcome

Please keep us posted.

Friedrich

Re: Renaming a previous install prior to new install

Super, I will turn that back on and give this a try. Thanks again!

Re: Renaming a previous install prior to new install

Hello,

Note: If you set DOTNET4_ASK_USER to "0" then it will never display the "Install Core PreRequisite?" question (silent or not-silent installs).

I would suggest to add the following three lines to the include script to handle your silent scenario (see attached screenshot). If the installer is running in silent mode then it will not skip the .NET4 install.

Does this help?

Friedrich

Re: Renaming a previous install prior to new install

Ok, thanks for the changes. My install is running very well now. I have one last issue with it though. I have it running as a silent install. I also have a prerequisite for .net framework 4. PCs that do not have .net framework 4 are not installing it like it should. I have other installers that are not silent installs and the prerequisites always work. I am thinking this is due to it being a silent install, what do you think? I did see under details for the prerequisite that it has a ask user area. I am going to try and change ask user from a 1 to a 0 and see if that helps. Any info would be great.

Re: Renaming a previous install prior to new install

Your installer HAS an UAC-manifest and is UAC-aware and UAC-compliant

What value does your %DATAPATH% have in a typical update scenario? Just for fun, add a "Display Message Box..." script function before the first Copy File(s) command and display the value. What value is displayed?

BTW, and I just noticed that you are using this in some Copy File(s) commands:

Source: %DATAPATH%\help\*.*
Destination: %_SB_INSTALLDIR%\help\*.*

The Destination specification is incorrect. It should be:

Source: %DATAPATH%\help\*.*
Destination: %_SB_INSTALLDIR%\help

And in another command, you are using this:

Source: %DATAPATH%\crystal
Destination: %_SB_INSTALLDIR%\crystal

The Source specification is incorrect. It should be:

Source: %DATAPATH%\crystal\*.*
Destination: %_SB_INSTALLDIR%\crystal

Friedrich

Re: Renaming a previous install prior to new install

I see. Well I changed my script to not poll or use anything in the windows folder anymore. I also used message boxs in my script to confirm my datapath and callingpath are being collected right. So far both of those message boxes are confirming that it has the correct value. Neither of these issues have fixed my issue though.

Could this be because my installer and applications do not have a UAC manifest?

Re: Renaming a previous install prior to new install

Thank you for your kind words

I think the copy process does not work correctly on some machines (with UAC enabled) because your source location is still incorrect on these machines. I would suggest to add some code to the script to detect such an incorrect source location scenario. It's not caused by the elevated running installer. "Something" in your application design is not UAC-aware/compliant.

I noticed that you read from a protected folder (e.g. %WINDIR%\aas2.ini to set the %CALLINGPATH% value). Only elevated running and UAC-aware!!! applications can write to this INI file. So I think that one of your apps that previously wrote the path to this INI file is not UAC-aware and as a result, virtualization kicks in and redirects the write action to another folder. So the "real" %WINDIR%\aas2.ini does not have the value you are looking for, only the virtualized one.

You should never store your data in the Windows folder. You have to make your applications UAC-aware to follow the Windows development guidelines.

Does this help?

Friedrich