I'm writing my first destop app under Vista and VS 2005 C#. Every time I try to run the app through the debugger I get "The requested operation requires elevation."
After searching several websites I have tried signing the application and adding a manifest.
<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urnchemas-microsoft-com:asm.v1" xmlns:asmv1="urnchemas-microsoft-com:asm.v1" xmlns:asmv2="urnchemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<requestedExecutionLevel level="requireAdministrator" />
<defaultAssemblyRequest permissionSetReference="Custom" />
<PermissionSet class="System.Security.PermissionSet" version="1" Unrestricted="true" ID="Custom" SameSite="site" />
I'm using the following DLL from OpenNETCF.org: OpenNETCF.Desktop.Communication (RAPI wrapper).
When I run the EXE by itself it will run after it asks if it is allowed to run. Is there anyway to turn that off so the user won't see it?
And how can I get it to run through the debugger?
It sounds like you are trying to use the debugger from a non-elevated context to start an executable that requires elevation to run (see: requireAdministrator in your manifest). To work around your problem, I reccomend you run VS 2005 (or whatever you are using to start your debugger) elevated when you need to debug an application which is going to require running as a full administrator. You can generally do this by right-clicking on the shortcut or exe in question, and clicking "Run as Administrator".
You can't bypass the prompt, in any case - not if you want your application to run as a full administrator. If you're authoring your application with a standard, limited user in mind (one who can't stomp all over c:\windows and clobber HKLM), then I'd suggest you try to change the 'requestedExecutionLevel' to 'asInvoker' and see if you can design your application to work that way - the vast majority of applications don't really need to be run as an administrator. You'll be doing your users a great service by authoring with the standard user in mind.
You probably want to read up on UAC, per-user applications, and related topics.
I've tried running it as "asInvoker" and "highestAvailable" and it won't run.
I'm not sure what is causing the app to think it needs administrator rights.
I've even created a brand new windows application that has nothing in it and I get the same message. I have to be doing something wrong.
By "it won't run" above, do you mean that you're getting the same error when you try to launch the application from a non-elevated instance of your debugger?
Is that an embedded manifest, or an external one? If it's an external one, it might be cached, which could be adding to confusion. You probably want an embedded manifest.
If you're using an embedded manifest, take a look at the exe; is the manifest being embedded at RT_MANIFEST, 1? Or, "RT_MANIFEST", 1 (forgetting an include in a .rc file can cause that to happen. there is a difference between the number RT_MANIFEST (24) and the string "RT_MANIFEST").
You can compare against a working one on your vista machine by opening Vista's notepad.exe inside of a resource viewer (or Visual Studio), and then see if there's what if any difference there is between your exe and that exe.
Yes. I got the same message "The requested operation requires elevation." when I ran the application using F5.
All I did was open a new instance of VS2005 and created a new windows application. I then pressed F5. I did not add a manifest file. There is no manifest file.
How do I look at the EXE? How do I open notepad inside of VS?
When I open the EXE that I created, it gives me a tree:
When I open NOTEPAD.EXe, it gives me a tree:
Mine says [Netural] under version and notepad doesn't.
This still doesn't tell me why my EXE requires elevation. All I did was create a windows application project and try to run it.
I'd discourage you from mucking around with what words do and don't appear in your 'version' resource; use a manifest. The 'update' thing looks to be triggering installer detection, but who knows what else will cause it to trigger? A manifest declaring a requestedExecutionLevel will consistently cause that problem not to happen for you. It also turn off file and registry virtualization, which you ideally don't need, if you're writing a new application and have the standard user in mind.
As far as the resource trees; apparently 'RT_MANIFEST' shows up as 'MUI' in your resource viewer - take a look at MUI->1; I think you'll see a manifest in there. In any case, a manifest is currently missing from <filename>.exe's resource view - something in your build process is causing the manifest to not get embedded, or perhaps you are looking at/debugging the wrong exe (release vs debug?). That may be why playing around with different manifest settings was having no effect for you.