Compare scripts

[NewsArchive]

Hi Friedrich,

Is it possible to do a source compare so I can compare 2 scripts? I've made
some tweaks in the last month and would ideally like to (say) export to xml
so I can see the difference between the 2.

Geoff

[NewsArchive]

Hi Geoff,

> Is it possible to do a source compare so I can compare 2 scripts? I've
> made some tweaks in the last month and would ideally like to (say) export
> to xml so I can see the difference between the 2.

What you can do is to use 'File' | 'Save Script Text to File...' to export
the script text to an ASCII text file.

Friedrich

[NewsArchive]

This is exactly what I want.

Thanks

Geoff Thomson

[NewsArchive]

Hi Friedrich,

I've been struggling with an issue for some time, and it looks like I've got
to the bottom of it. I am uncertain when this came in (I think it was about
3 months ago), but it seems like in recent versions of SetupBuilder, I have
to first compile the script in the compiler, before saving - and then
compiling in automatic mode. My impression is that there's something
initialised in the script itself when you do this, which does not get done
if you just save and close from the compiler (and then compile in automatic
mode).

I have exported the same script before and after compiling from the IDE and
you will notice that on export (after compile) all the compiler variables
are primed.

In the meantime, I can work around this by compiling after changing the
script (before a silent compile), but it would be worthwhile having this
resolved, as it has caused me some inconvenience.

Export before compile:
https://www.dropbox.com/s/v9dc6e7u451gj5a/ApplicationInstall20170103.txt?dl=0

Export after compile:
https://www.dropbox.com/s/ypuczvwn91y4pgg/ApplicationInstall20170103%20compiled.txt?dl=0

Geoff

[NewsArchive]

Hi Geoff,

Hmmm, nothing changed in the compile / save / export functions for a very
long time. I'll try to reproduce this and get back to you.

Thanks for the report!

Friedrich

[NewsArchive]

Hi Geoff,

What are the steps required to reproduce the bug?

At the moment I have no idea where all these \\\\\\\ are coming from.

Friedrich

[NewsArchive]

Hi Friedrich,

If I open the script in the SetupBuilder IDE, save and close. Then I compile
using command line silent/auto compile, the install does not install the
updated program files (that's the symptom).

If I open the script in the SetupBuilder IDE, compile, save and close. Then
I compile using command line silent/auto compile, the install installs the
updated program files.

I noticed that if I export the script to text after compiling in
SetupBuilder IDE, then variables are reconciled with their values. If I
export before compiling, then the variables are not replaced with their
compile-time values. That might be a red herring though.

Geoff

[NewsArchive]

Hi Geoff,

Not easy to debug. I'll see what I can do. Thanks for the additional
information.

The question is, is this a project logic issue (e.g. you did not set some
"default" values) or a compiler issue (bug in my compiler code). I'll try
to develop a script that can reproduce this issue. But nothing changed in
the compiler variable handling since November 2013.

The compile process in "compile -> save -> close" might set (or change) some
compiler variable values and the 'save' action stores the new value(s) in
the project file.

I'll investigate it.

Friedrich

[NewsArchive]

Hi Friedrich,

That was yesterday. Today seems to be a different day. What must have been
happening is the UACLEVEL must have been set to 3 when I did a compile
making the permissions (as below) a non-issue.

It looks like my symptom is related to a permissions issue. I've attached a
screenshot of what I need to do in order for a user (non-Admin) to run the
install asInvoker. The initial install runs as RequireAdministrator - I have
a separate install exe (same script, but with UACLEVEL set to 1 - and
skipping out the admin functions like setting permissions and firewall
exceptions which would have been done on the initial install) for the
update. I've also attached a screenshot of what I have done on the SB script
to get it to do what I want. I'd greatly appreciate a pointer on how to set
the Grant File Access to behave for the user access how I need it to behave.
If I manually set the Write Permission for the user, the update install runs
as I need it to run. I am wanting to do this step automatically in the
initial install.

Thanks for your help.

Geoff

[NewsArchive]

Hi Geoff,

to be honest, I have never tested something like this on modern Windows
operating systems because it's against all Windows development guidelines.
It is not allowed to change the permission of the "Program Files" folder or
its sub-folders. You NEED administrator execution level privileges to write
to the "Program Files" folder tree.

I have to setup a clean VM to test it. But it's definitely against "the
Windows rules" (non-elevated running apps should never be allowed to write
to Program Files).

Ten years ago, in 2007, I posted this method for old legacy and
non-UAC-aware apps:

http://www.lindersoft.com/forums/showthread.php?2379

BTW, instead of using "Everyone", you should use "S-1-1-0"

Friedrich

[NewsArchive]

Hi Friedrich,

First up, thanks very much for your patience in answering my questions in
such detail. I'll try to elaborate as to why I'm needing to do this.

Some detail: On my test PC, UAC is turned on, User is an Admin account. When
I run an install compiled with UACLEVEL=AsInvoker, the EXE install is
running with user privileges (since the UAC prompt to elevate to
administrator is not necessary). A lot of times in practice a user account
will be required to update the application folder, since they often don't
log on with an admin account. The updates should run automatically (not
requiring user admin access), so the program files can get updated
automatically, hence requiring write access at the user level.

With the initial install (UACLEVEL=RequireAdministrator), I have created the
folders with the shares and the firewall exceptions necessary for the
application, so this is not necessary in the update install.

In the update install, I need to avoid the elevation prompt, but still have
the ability to update the C:\Program files\MyProduct folder with the updated
program. If I cannot avoid the elevation prompt, I will have a lot of users
not updating (because of not being able to access the admin account). I am
loath to move away from using the Program Files folder for my application
since it's clear that MS is moving folk in that direction.

Does that make sense?

Maybe the question I should be asking is how are others updating their apps
in the Program Files folder without the elevation prompt?

Geoff

[NewsArchive]

Hi Geoff,

> Does that make sense?
>
> Maybe the question I should be asking is how are others updating their
> apps in the Program Files folder without the elevation prompt?

Yes, it makes perfect sense. In general, updates in the "Program Folder"
tree are not possible without elevation prompts. That's expected (for
security reasons) and is by Windows design. I agree, this is (very)
suboptimal and a design failure (IMO).

I have been working for quite some time on a new "SBRemote" remote feature.
Russ Eggen was one of my main SBRemote testers and inspirators (he performed
SBRemote powered installations and updates on large environments with 500+
machines). Unfortunately, due to Russ's bad health, we had to stop last
September. A lot of test results could not be submitted anymore. R.I.P.
Russ.

This feature can install and update (elevated) in the Program Folder tree
without any elevation prompt:

http://www.lindersoft.com/forums/showthread.php?43969-Remote-Install-Update&p=79366#post79366

http://www.lindersoft.com/forums/showthread.php?44068
http://www.lindersoft.com/forums/showthread.php?46924

Still working on it and I plan to start a new round of tests soon.

Friedrich

[NewsArchive]

Hi Friedrich,

I am happy to assist, as the ability to perform an update install from a
user account is becoming very important for us. At least 50% of our Veculim
support is around updating - and having the ability to do this would reduce
the support significantly.

Geoff

[NewsArchive]

Hi Geoff,

> I am happy to assist, as the ability to perform an update install from a
> user account is becoming very important for us. At least 50% of our
> Veculim support is around updating - and having the ability to do this
> would reduce the support significantly.

Wow, that would be great. Thank you very much! I'll keep you posted.

Friedrich

[NewsArchive]

We have received another related report. I have opened a ticket. There
seems to be a long-standing bug in the "Save Script Text to File" function.

Friedrich

[NewsArchive]

Hi Friedrich.

Let me know if you need anything else to assist in tracking this down.

Geoff

[NewsArchive]

Hi Geoff,

>
> Let me know if you need anything else to assist in tracking this down.
>

Thank you !!! Still working on it, not a trivial task :-(

Friedrich