WyUpdate not prompting for Elevation for "Program Files" based installation [Solved]

[BenOK350]

I have a problem with WyUpdate not asking for elevation when it needs to, and so my updates are failing with "Access to path is denied" errors.

Our application is installed to "Program Files [(x86)]\OurApp", which non-admin users on Win7 can't write to. WyUpdate.exe is right alongside the installation and executable. When running as an admin, the update goes fine, but as a non-admin, the next button doesn't have a sheild and elevation isn't prompted, resulting in a failed update.

I've stepped through the code, and ran onto frmMain.OnlyUpdatingLocalUser(). It doesn't seem to catch that the current, non-admin user can't write to the installation folder, and returns false. When I alter the return value to true, elevation is prompted and the installation continues successfully.

Shouldn't it be prompting for elevation when installing into a folder like Program Files, or am I doing something wrong? We just had a hellacious day yesterday dealing with support calls - my fault for not better testing with a Win7 non-admin . But I want to get to the bottom of this and do it the right way. Any suggestions?

[Sam]

Hey Ben,

Shouldn't it be prompting for elevation when installing into a folder like Program Files, or am I doing something wrong?

Yes, it should, and does, prompt for UAC elevation on all of our test machines.

I've stepped through the code, and ran onto frmMain.OnlyUpdatingLocalUser(). It doesn't seem to catch that the current, non-admin user can't write to the installation folder, and returns false. When I alter the return value to true, elevation is prompted and the installation continues successfully.

Are you running a custom version of wyUpdate? Did you modify the wyUpdate source code in any way? Because "OnlyUpdatingLocalUser()" should return "false" on non-admin accounts. So that function is working correctly and returning the correct value. Did you change how that value is used?

Try using our pre-compiled version of wyUpdate. Does it work as expected?

[BenOK350]

BTW - version of WyUpdate I am looking at is 2.6.16.4

Stepping through further, I notice that the call to HaveFolderPermissions() is returning true, even though the standard user does not have write access to the installation folder. Is this correct behavior? It evaluated for true based on the following FileSystemAccessRule:

IdentityReference.Value = "BUILTIN\USERS" (which of course the user is a member of)

FileSystemRights =
ReadData | ReadExtendedAttributes | ExecuteFile | ReadAttributes | ReadPermissions | Synchronize
(which does not constitute write access)

Is this correct behavior? Shouldn't this method have been written to return false under this circumstance?

Before I go off and write a custom version of WyUpdate I want to make sure I'm on the write track.

Thanks in advance for any help!

[Sam]

Stepping through further, I notice that the call to HaveFolderPermissions() is returning true

You're using the subversion trunk, not version 2.6.16.4. The "trunk" of the wyUpdate subversion repository is to be considered "pre-beta" code. Sometimes it doesn't even compile. So never ever use "trunk" code in production (unless you've done extensive testing).

The "HaveFolderPermissions()" function in particular is a newly added function that has gotten almost no testing.


If you want the latest stable wyUpdate code, get it here: Open Source Updater: wyUpdate.

[BenOK350]

Holy crap yes I did check out the trunk. I saw the version I wanted in assemblyInfo and thought I was good. Well that would explain it! Thanks SO much. Thought I was going nuts.

Now another question (with a quick answer I fear):

When I first started using WyUpdate a year ago, I made what I now consider the unwise decision to host a custom version of WyUpdate. It had **ZERO** code changes, just added 20 to the version number. I thought it would be a good idea to have there in case I ever absolutely needed to make changes, and decided to do it upfront before I deployed client.wyc to a bunch of customer locations.

Well last week I was getting an unrelated WyUpdate error in my testing and thought I'd just update to the "latest" version, which led to this trunk faux pas.

Point is, I wish now I'd just stuck with WyUpdate updating itself from your servers, and this never would have happened. Is there any way to change this for my existing install base (via an update, etc) without doing what amounts to a manual reinstall with a new client.wyc?

[Sam]

Point is, I wish now I'd just stuck with WyUpdate updating itself from your servers, and this never would have happened. Is there any way to change this for my existing install base (via an update, etc) without doing what amounts to a manual reinstall with a new client.wyc?

Yes, delete the "self-update" sites you have listed in File -> Properties -> wyUpdate, Press OK, then click "Build wyUpdate". This will generate the latest "client.wyc" file with our hosted update sites (code.google.com and wyday.com). Then simply add this client.wyc file to all the new versions in wyBuild.

The next time your users update they'll get the client.wyc file, and thus every subsequent update will use our self-update sites.

Does that make sense?

[BenOK350]

Thanks Sam, yes that does make sense. For some reason I had myself under the impression client.wyc couldn't be included in a patch. This helps a lot.

Thanks again for your help.

One last question - in order to reduce friction for users during updates, I am considering having my app installed into the user profile rather than "Program Files" so WyUpdate won't need to request elevation. I am thinking %LocalAppData%\"MyApp" (\Users\Username\AppData\Local\"MyApp"). Do you guys think this is a good place, or in general that this is a sound idea?

[Sam]

Do you guys think this is a good place, or in general that this is a sound idea?

Yes, this is a good place if you don't mind non-admin users being able to update your app. Some IT administrators don't like this. So, if I were you I'd give your end-users the ability to install to either Program Files or to AppData.

[BenOK350]

Great - that makes sense. Thanks again for the prompt help!