Networks

Our forums are currently in maintenance mode and the ability to post is disabled. We will be back up and running as soon as possible. Thanks for your patience!

Question

Gravatar
0 Votes
Locked

Request UAC elevation at runtime?

By Slayer_ ·
I have a legacy VB6 Program that occasionally needs UAC elevation to do some things (mostly copying OCX's and DLL's to system folders).
However, this is only 5% of its function, the rest does not require UAC.
Is it possible to code it to request UAC elevation only when needed, thus not needlessly prompting the user for UAC each time the program is run?

I did find on the internet, some people wrote an elevation command, the problem with this is that it causes each OCX and DLL to require a UAC prompt (about 30 of them each time) so this is no good.

I'd also rather not recursively run the program, the program shelling to itself but with elevation, that could get nasty.

Anyone got any ideas?

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Answers

gravatar
Collapse -

Reponse To Answer

by Slayer_ In reply to these may help

The first one I already knew about, but that only works if you want UAC every time, I only want certain sub procedures to need UAC elevation (The file copying).

The second link doesn't make much sense to me.


Thanks for the suggestions though.

gravatar
Collapse -

Reponse To Answer

by markp24 In reply to these may help

Ahh I see, this one may be beyond me, i play with VBscripting,, I did ask a developer here regarding uac issues and our software, they are using some "manifest" technique. Im not that familiar with that but maybe if you look into that it mgith lead you somewhere?

gravatar
Collapse -

Can you move the elevation-dependent code

by seanferd In reply to Request UAC elevation at ...

to a separate executable?

gravatar
Collapse -

As seanferd suggested

by Tony Hopkinson In reply to Request UAC elevation at ...

best bet is another executable, runs up if authorised does it's stuff.
You can elevate an app easy enough, but you can't 'erm "unelevate", that can get very messy, particularly with things like user profiles, end up adding stuff to the user you elevated to instead of from. Very messy.

gravatar
Collapse -

Reponse To Answer

by Slayer_ In reply to As seanferd suggested

Once elevated, it shouldn't cause any additional problems. It should only need to run this code once every few months, but the EXE it self runs at least 10 times a day, so a UAC prompt each time would be aggravating.

An additional EXE is a possibility, and its probably the way I am going to have to do this.

gravatar
Collapse -

Reponse To Answer

by Tony Hopkinson In reply to As seanferd suggested

It's by far the easiest.
When we did something similar, there was brave attaempt by management to "keep it simple", and not have another process.
Turned out to be not simple, not even a littel bit...

gravatar
Collapse -

Reponse To Answer

by markp24 In reply to As seanferd suggested

wow interesting method, im happy you guys had a good answer

gravatar
Collapse -

Reponse To Answer

by seanferd In reply to As seanferd suggested

Whatever you do, good luck with it.

Do you think the company will still be using VB6 code in ten years? Inertia can be an amazing thing, but I can't feature VB6 having the same staying power as, say, COBOL.

gravatar
Collapse -

Reponse To Answer

by Slayer_ In reply to As seanferd suggested

Another 5 years at least. It handles our installations and dependencies. VB6 has the advantage of being fully supported in Windows XP and up from fresh install. One of the things it installs is .net 1 through 3

Back to Networks Forum

Start or search

Related Discussions

Related Forums