CommonAppDataFolder and UAC

As far as I can tell there is no reason to show a UAC prompt to the user, I can read/write to that directory as a non-admin user in Windows Explorer without any issues.

Yes, but here's the rub, if an admin writes to the common appdata folder, then a non-admin tries writing to the folder the writing will fail (unless you set the appropriate ACL settings for the files).

Thus, it doesn't *always* require admin permission to write to the folder, just when the first user to write the file was admin.

Does that make sense?

Ok, I can set permissions on that directory during the initial install.

Once I do that is the updater smart enough to realize that it doesn't need to be elevated or else is there some flag or option to force UAC not to happen?

wyUpdate doesn't dynamically check the Common AppData folder to see if the limited user has permission to update your specific files. It just broadly assumes that if the user is a limited then it will need to elevate to write to that folder.

We might make it possible to dynamically check this in the future, but for now you'll either have to modify wyUpdate, or install to a folder that the limited user actually has permission to (e.g. AppData).

If you do modify wyUpdate then we'll gladly accept the changes you make. You might want to see the "HaveFolderPermissions()" function in the trunk version of wyUpdate. (See: frmMain.UserElevation.cs).

Of course, there are other options to update without requiring admin permission.

Having an install per user won't work so AppData isn't an option. The goal of the work I'm doing now is to support the application being updated without an admin being involved like the current system I'm using of a new WiX installer for updates.

I'd rather not going messing around in another project's source code. When will you add that ability? Will it be in a couple of weeks or more like a couple of months?

In 2.6.18 (which we're trying to release ASAP) we're adding the ability to dynamically check just the "Your program's folder" to see if the user has the ability to write files to that folder. So if you're installing your main app to that Common App Data folder, and you've set the ACL setting correctly, *and* you're adding these files to the "Your program's folder" in wyBuild, then wyUpdate will be able to handle limited users installing to this folder without prompting for UAC.

That sounds like what I'm looking for. Do you think ASAP will be in the next two weeks?

Yes.

Will the new version be soon? I'm about to give the application to testers and I would like to give them a version that doesn't UAC prompt.

We're still fixing a couple of other bugs unrelated to this new functionality. If you don't want to wait for that I can send you a version just with the more flexible UAC behavior.

Ok, the tester raised a bug about it so I need to fix it. Please email me the update to the email address I used to sign up to the forum.

Do I need to do anything other than replace the wyupdate.exe I include with the application?

I have updated to the latest wyUpdate.exe and it works fine when copying files to the directory but I have installed AVG and it is flagging wyUpdate.exe as a virus:

http://i.imgur.com/AtXsO.png

The source of the error in AVG was its IDP component which detects viruses based on behavior.

I searched your forum and I found someone with a similar issue here - https://wyday.com/forum/t/492/instantupdate-exe-detected-as-malware-at-avg/#post-2447

Boy do I hate poorly designed virus scanners. I'll call up these morons and see what they can do about it.

In the meantime, it should go without saying that wyUpdate is not a virus. But if you don't believe me you can checkout the source code and build it yourself:

svn checkout http://wyupdate.googlecode.com/svn/trunk/ wyupdate

Just click the "allow it" button on the "threat" prompt.

Can you please keep me updated with what AVG says. Allowing is not a problem for me but it won't work with thousands of end users using the application.

wyupdate doesn't give this error when you run it in C:\Program Files\YourApp, correct? It just gives it when you're running in the common appdata folder?

My guess (having not yet called AVG) is that they're using sloppy heuristics that say any *.exe running in AppData or CommonAppData is a "threat".

Try running in C:\Program Files\YourApp. Do you get the same error?

Yes I also get the warning when installing to C:\Program Files

Is this happening when wyUpdate is self-updating?

Yes

Sorry, I should've made myself more clear-- is this only happening with self-updates. That is, when wyUpdate is not self-updating is this happening?

Also, what AVG product are you using? Is it the free anti-virus product?

Yes the free virus scanner version of AVG.

I'm not sure whether wyUpdate is updating itself. Would it update itself when you haven't released a new version in the last couple of weeks? I do know that when testing I've deployed some updates for my application to the server for wyUpdate to download.

Would it update itself when you haven't released a new version in the last couple of weeks?

No, it wouldn't. However it would self-update if you're using an old version of wyUpdate. So, the question is this: what version of wyupdate.exe are you using? Right click wyUpdate.exe, click Properties, and look at the version number.

The wyUpdate.exe version included with the initial msi installer is 2.6.16.4

Have you spoken to AVG?

I have an authenticode certificate that I'm using to sign the installer and I experimented signing wyupdate.exe with the certificate and the error has yet to reappear. I'm guessing it isn't flagged anymore because whatever heuristics the anti-virus uses to determines whether a program is a virus sees that the exe is authenticode signed and so doesn't flag it.

Could you start authenticode signing your builds of wyupdate.exe?

We do sign wyUpdate. Were you building it from source?

I ended up building from source code after the delay in the next release for UAC.

It looks like as long as wyupdate.exe is signed then AVG won't complain about it.