I have a method that modifies or saves a file in C:\ drive when it is called, but if user don't have access, it throws an exception.
How can the user be asked with UAC if he allows the method to make changes on C:\ drive instead of throwing an exception?
See this post on SO. To make it easier I post part of the accepted solution.
I don't believe that it's possible to elevate the currently running process. It is built into Windows Vista/Seven that administrator privileges are given to a process upon startup.
If you look at various programs that utilize UAC, you should see that they actually launch a separate process each time an administrative action needs to be performed (Task Manager is one, Paint.NET is another, the latter being a .NET application in fact).
The typical solution to this problem is to specify command line arguments when launching an elevated process, so that the launched process knows only to display a certain dialog box, and then quit after this action has been completed. Thus it should hardly be noticeable to the user that a new process has been launched and then exited, and would rather appear as if a new dialog box within the same app has been opened (especially if you some hackery to make the main window of the elevated process a child of the parent process). If you don't need UI for the elevated access, even better.
You can indicate the new process should be started with elevated permissions by setting the Verb property of your startInfo object to 'runas', as follows:
startInfo.Verb = "runas";
This will cause Windows to behave as if the process has been started from Explorer with the "Run as Administrator" menu command.
As Marco says it can't.
You can't unelevate an elevated process either.
The security improvement UAC was for was to kill programmatic elevation, as it was a huge (and thoroughly exploited) threat vector.
A nice way of doing it is rejig your process as a series of tasks. Identify those that need elevation, run up a "TaskProcessor", pass it the tasks. Calling program then checks they've happened, if so continues. You can do grouping, dependencies etc with this and it's nice and reusable if you put a bit of thought in.
Seems overkill for one file admittedly.
Bear in mind just requesting elevate doesn't mean it will be granted or even that the account being elevated to has the required privilege. So if you can't put that file on the root, is your application in a valid state.
Also if you are supporting pre-vista OSes, XP low rights users, terminal services etc, even UAC being off in W7, you can get some apparently illogical behaviours anyway.
I would highly suggest that you simply disallow saving files into locations that the Windows team has said requires additional priviledges to do.
In other words, start the save as dialog in the Documents area and let them choose from there. Then, capture the exception and show it to the user about lack of priviledges to write to those special directories.
I would think that a user would prefer to know that you aren't bypassing the built in security. Believe me, I think it's a pain that IIS doesn't allow me to open notepad and edit a file under my local inetpub directory, but at the same time I'm very happy it does stop me.
