views:

158

answers:

1

Hi, a lot of my programs require the ability to write files to the hard drive. When I first made these programs for XP they worked great. Now I'm less ignorant about UAC (got a new laptop recently). And for future customers...I've noticed the potential for a LOT of annoying error messages....and quite frankly if the program can't write data to the hard drive or thumb drive it's on...there's no point to running it....

I've tried multiple times to build in the manifest a requirement for administrator or user access....I'm not sure if anything less would solve the problem...but have failed because click-once has security features in place to prevent me from doing so.

I'd rather not have to tell my customers how to make the program run as an administrator by editing the file's properties...I'd much rather have a convenient pop up like what you'd see new programs such as Itunes or Filezilla show if they were in conflict with UAC requesting the privileges they need.

I'd really like to do this but have had little success.

Any and all advice that can remedy this grievous problem appreciated.

Thanks.

+4  A: 

First, let me tell you that the design goal of ClickOnce deployment is not to require administrative privileges. This translates into "you can't elevate privileges when running a ClickOnce application".

When Windows Vista came out, Microsoft published guidelines on where to store files that you want to be able to update. NOTHING should be placed in Program Files; they generally recommend LocalApplicationData or Isolated Storage. The same issues are in place for Windows 7.

So where are you trying to write data for your customer?

RobinDotNet
This program is portable, meaning it will store data in whatever location it is installed to. Commonly my customers will install it to program files (out of familiarity) or they will install it to a thumb drive. I have noticed the problem occurred for me when the program was in program files and I don't remember if I tested it on the desktop or a thumb drive before disable UAC out of annoyance. But this program could exist potentially anywhere on the hard drive, really....
Assimilater
If you want to store the application in Program Files, you can not use ClickOnce deployment. It does not support this. As I noted about the design goals of ClickOnce, it is installed under the user's profile in obfuscated folders, so the user can't mess with it. Also, I advise you not to disable UAC, since it does help keep your computer safe, but that is, of course, your choice. Also, for ClickOnce, you have to think about where you want to store the data. I don't store mine w/the deployment files because there are new folders with each version deployed.
RobinDotNet
One other note -- I wrote this blog entry to help people store their data and not lose it between updates. It might be helpful to you. http://robindotnet.wordpress.com/2009/08/19/where-do-i-put-my-data-to-keep-it-safe-from-clickonce-updates/
RobinDotNet
I don't know why I would lose data between updates, but you are probably using a more sophisticated method of storing data than I do....I just use text files...and i use a rather weird setup because I hate how clickonce installs the program. I have the deployment install a setup program which goes through my install process so I can show a user license agreement and installation options to my pleasing. The user decides where to install the actual program and the program stores data in its directory location. It would work quite beautifully without this hiccup...
Assimilater
Every time the user installs an update, it creates new folders and runs from there. That's why I move the data -- to ensure that my data doesn't accidentally get left behind. I don't understand why it matters to the user where the app is installed; he shouldn't be messing around with the deployment file anyway (which is verified by C/O by the way). If this is really important to you, you can not use ClickOnce deployment. It MUST be installed in the user profile ClickOnce cache folders.
RobinDotNet
Maybe I should change my approach to data storage then. Right now it's a bunch of files. If I can figure out a way to compact it all into one file that would add the portability I desire. That would also remove the grief over having access to the exe file.
Assimilater