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..