UAC Issues On Vista

  • Thread starter Thread starter Stephany Young
  • Start date Start date
S

Stephany Young

Even though I had my roots and highlights redone just a few days ago, I
don't understand why I appear to be having an ongoing blond moment.

Is it just me or do others among you not 'get' how to make C# and VB.Net
applications play nicely with the the UAC on Vista.

I have read and reread everything I can find on UAC, 'strong-naming' of
assemblies, 'authenticode signing' of assemblies and, even though I'm not
your average thicko by any means, I just dont get it.

It seems to me that, to some degree it might be a case of "The Emporer's New
Clothes" and nobody is prepared to stand up and say "Stop! Enough already!".

If anyone has a blow-by-blow of how to make it work and is prepared to share
their knowledge/experience Then it would be most appreciated.
 
Stephany Young said:
Even though I had my roots and highlights redone just a few days ago, I
don't understand why I appear to be having an ongoing blond moment.

Is it just me or do others among you not 'get' how to make C# and VB.Net
applications play nicely with the the UAC on Vista.

I have read and reread everything I can find on UAC, 'strong-naming' of
assemblies, 'authenticode signing' of assemblies and, even though I'm not
your average thicko by any means, I just dont get it.

http://blogs.msdn.com/cheller/archi...est-in-an-assembly-let-me-count-the-ways.aspx

http://www.devx.com/VistaSpecialReport/Article/33856/1954?pf=true
 
Thanks for your response Dominick.

I've got no issues at all with the concept of 'least privilege' or for that
matter being to elevate the privilege of a process or sub-process when it is
absolutely necessary to do so.

To illustrate my issue, consider an appplication done in VB.Net (for the
sake of argument):

The project comprises 1 form (Form1) which is
designated as the startup form.

The form has 1 button with handler for it's
Click event.

The code in the event handler is simply:

MessageBox.Show("Hello World!")

Compile the project resulting in TestApp.exe

If you 'run' the project in the IDE then no problems at all. The
application behaves as expected.

Run the project outside the IDE then we are told that an undentified program
(from an unidentified publisher) is attempting to access your computer. On
then need to give assent (for an administrator) or provide an administrative
username/password (for a standard user) before the program will run.

How to prepare the application so that it runs without this palaver is the
issue. I just don't get it.
 
Stephany Young said:
Thanks for your response Dominick.

I've got no issues at all with the concept of 'least privilege' or for
that matter being to elevate the privilege of a process or sub-process
when it is absolutely necessary to do so.

To illustrate my issue, consider an appplication done in VB.Net (for the
sake of argument):

The project comprises 1 form (Form1) which is
designated as the startup form.

The form has 1 button with handler for it's
Click event.

The code in the event handler is simply:

MessageBox.Show("Hello World!")

Compile the project resulting in TestApp.exe

If you 'run' the project in the IDE then no problems at all. The
application behaves as expected.

Run the project outside the IDE then we are told that an undentified
program (from an unidentified publisher) is attempting to access your
computer. On then need to give assent (for an administrator) or provide an
administrative username/password (for a standard user) before the program
will run.

How to prepare the application so that it runs without this palaver is the
issue. I just don't get it.

I did your example on this Vista Ultimate machine, using a Admin and
Standard accounts, ran it from the Bin directory and copied the exe to
another directory, even made a desktop short-cut to it, not one time did it
ask for permissions to run the exe with giving an Admin user-id and psw, for
a Standard account running the program.

The laptop came with Vista Home Premium on it using VS 2005 Express, which
was upgraded to Vista Ultimate.

If the machine has been upgraded with Vista over the top of an existing non
Vista O/S like XP, then there is no telling what's happening with Vista.
 
Interesting. You are reporting the same results I get with UAC 'turned
'off'. I assume that you do have it 'turned on'.

With over 5000 installs of various Windows versions going right back to NT
3.51 and Windows 3.1 I have yet to do an 'upgrade-in-place' type install and
I sure as <unlady-like language omitted> aren't going to start those sort of
silly games with Vista. More than 90% of the OS installation related
problems that I have to troubleshoot over the years has been on
'upgrade-in-place' installations. It's just not worth the hassle.

See my later post for where I'm up to.
 
Thank you both Dominick and Mr Arnold.

The content of the links you supplied filled in some of the gaps in my
understanding of how to embed manifests.

I found that some of the articles would explain one part very well but gloss
over the detail of another part but another article would flesh the
'missing' part out. I'm not criticising the writers because I know how easy
it is to assume that the reader already knows what your'e talking about.

The upshot is that, when you combine the pertinent bits from the various
articles, it all becomes clear.

One bit that has me perplexed though is that compiling a manifest as a
resource in the prebuild event using C# is fine but when running rc.exe in a
batch file it spits is dummy and thows an RC2135 error on one of the #define
statements - scary.

Anyway, I now have a managable kludge that will allow me to embed a manifest
in a VB.Net project that will have to do me until whatever Orcas is going to
finally be called goes RTM.
 
Stephany Young said:
Interesting. You are reporting the same results I get with UAC 'turned
'off'. I assume that you do have it 'turned on'.

Yes UAC is turned on. I made sure that UAC was on, because I had truned on
and off at times. It was on for sure both times I did your test example, and
it never asked for admin permissions for a Standard user account executing
the exe.
With over 5000 installs of various Windows versions going right back to NT
3.51 and Windows 3.1 I have yet to do an 'upgrade-in-place' type install
and I sure as <unlady-like language omitted> aren't going to start those
sort of silly games with Vista. More than 90% of the OS installation
related problems that I have to troubleshoot over the years has been on
'upgrade-in-place' installations. It's just not worth the hassle.

See my later post for where I'm up to.

The only other thing it might be is that you have complied this program on
an XP machine, and you're trying to run it on Vista.

My rule of thumb is build and deploy a program on the platform it's intended
to run on to avoid compatibility issues.
 
Stephany Young said:
Even though I had my roots and highlights redone just a few days ago, I
don't understand why I appear to be having an ongoing blond moment.

Is it just me or do others among you not 'get' how to make C# and VB.Net
applications play nicely with the the UAC on Vista.

I have read and reread everything I can find on UAC, 'strong-naming' of
assemblies, 'authenticode signing' of assemblies and, even though I'm not
your average thicko by any means, I just dont get it.

It seems to me that, to some degree it might be a case of "The Emporer's
New Clothes" and nobody is prepared to stand up and say "Stop! Enough
already!".

If anyone has a blow-by-blow of how to make it work and is prepared to
share their knowledge/experience Then it would be most appreciated.



How do your UAC settings look like? You can check this by running "Local
Security Policy" from "Administrative Tools"
I had the same issues when running beta's and RC's of Vista before, but I
never had this issue on Vista RTM, running C# applications (if that matters
at all) as standard user.
Also, make sure you have VS2005 SP1
http://msdn2.microsoft.com/en-us/vstudio/bb265237.aspx and VS2005 SP1
http://support.microsoft.com/kb/929470 installed?

Willy.
 
I assumed it was turned on but I did to have to ask just in case :)

Dev Machine = Windows Vista Ultimate
Target Machine = Windows Vista Ultimate
Both machines are members of the same Windows Server 2003 domain.

The target machine is a fresh install with all updates, joined to the domain
and no other tweaks.

The users are Domain Admins and Domain users rather than Local Admins and
Local Users. That could explain the difference in behaviour but I would hope
that something as fundamental as that would make no difference.

I'm not overly concerned that the behaviour that you observed was different
from what I observed because I'm well aware that one can observe different
behaviour on two machines that are ostensibly identical and that attempting
to determine the difference between the two machines is like attempting to
find a needle in a haystack.
 
Thanks Willy.

Been there and even got the tee-shirt for those two updates :)

The UAC setting are 'out-of-the-box'. Absolutely NO tweaks to the target
machine except for applying all the updates and joining a domain.
 
Stephany Young said:
I assumed it was turned on but I did to have to ask just in case :)

Dev Machine = Windows Vista Ultimate
Target Machine = Windows Vista Ultimate
Both machines are members of the same Windows Server 2003 domain.

The target machine is a fresh install with all updates, joined to the
domain and no other tweaks.

The users are Domain Admins and Domain users rather than Local Admins and
Local Users. That could explain the difference in behaviour but I would
hope that something as fundamental as that would make no difference.

I'm not overly concerned that the behaviour that you observed was
different from what I observed because I'm well aware that one can observe
different behaviour on two machines that are ostensibly identical and that
attempting to determine the difference between the two machines is like
attempting to find a needle in a haystack.

Maybe, you need to look at Group Polices for the machine on a domain, put
the solution in GAC so that it's trusted, possibly or check what can be done
with the .Net Framework Configurations' Runtime Security.
 
Stephany Young said:
Thanks Willy.

Been there and even got the tee-shirt for those two updates :)

The UAC setting are 'out-of-the-box'. Absolutely NO tweaks to the target
machine except for applying all the updates and joining a domain.

UAC settings may differ when Domain policies apply!
Do you run this application with full "administrator" privileges? For
instance by Right clicking in Explorer and "Run As Administrator" ? Also,
check the .exe properties -> Compatibility -> Privilege Level - "Run this
program as an administrator". If this option is enabled then you will always
get the UAC prompt.
Your application is not signed and does not have a UAC manifest included,
so, somehow it's forced to "run as administrator", hence the UAC prompt.

Willy.
 
Thanks again Willy.

Me issues were not really to do with the behaviour of UAC, rather they were
to do not being to come to grips with how to make an application 'play
nicely' with UAC. After extensive research, the methodolgy still seemed a
bit on the esoteric side, however, with another couple of pieces falling
into place as a result of response to my OP it is now a lot clearer and I
now have apps with imbedded manifests that enable them to 'play nicely' with
UAC.

It's all part of the ever-continuing learning curve, but when you don't know
the answer the question is always hard.
 
Back
Top