I do not feel this rids you of the "Develop as
admin" at all, becuase in a day to day
operation you should not be logging in as an admin. Even
if you are a system administrator your day to day user
should be a standard user and not an admin.
Just remember... DEVELOPING, RUNNING, or THINKING about
running as an ADMIN is BAD!
You are mixing security metaphors. Developing as
non-admin is a user-based security concept. The
ClickOnce security settings in VS 2005 are a Code Access
Security concept. CAS and user security are disjoint and
complementary. I can't think of any way that this
changes developing and non-admin concepts.
Brian: Sure - it's a little counterintuitive, but here's
my line of thought:
*one* of the bad things about developing as admin is
that you produce applications that might require admin
privileges without realizing this. (There are other
caveats such as a lower security bar on your dev machine
for hackers and such..)
*so* - What happened if you gave your application
security settings at debug time that made it *behave* as
if it was running as a lower privilege user (but not
really). For example, a low priv. user cannot have
access to the c:\windows dir. So you prevent that in the
clickonce settings. actually - you prevent your app from
doing *anything* that it does not need (perhaps you'd
want to set it's permission levels to execution, UI and
nothing more at first and then slowly add permissions as
you need them). If you do that, each time your app does
something it is not supposed to be doing, you'll get a
runtime exception, which is what you want.
Yeah, it;s not an identity security thing, but clickonce
seems to give you the same benefit: telling you when you
step out of bounds..