Question

From what I have gleaned from reflector, RunWithElevatedPriveleges simply reverts the current thread identity to the base (non-impersonated) identity. This makes perfect sense in the case of code running inside the WSS application pool, since the base service account is a super-user. Does it have any effect when running in an external (console or service) application, when no impersonation exists? I'm guessing not, but I'd like to know for sure. I've seen varying opinions on this from googling.

Was it helpful?

Solution

Normally Runwithelevatedprivileges will get your code running as the app pool identity, but it doesn't work from the console. What we've done in this case is either use runas or a set the identity of a scheduled task to the same account as the app pool identity.

OTHER TIPS

I think it would if you ran the executable under one account and then changed it's credentials with code (like SP does). Otherwise, it cannot elevate to permissions it didn't have at start without some way of generating a Credentials object.

RunWithElevatedPriveleges don't work when HTTPContext is null. In console, HTTPContext is null.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top