0

I know there are plenty of similar questions out there like this one how to get %AppData% path

But mine is different:

1.I have two account:

Admin- Administrator account
Test- Non-Administrator account

2.Run my project using VS2013 as a Administrator cause the project requires to have elevated permissions. Then using the following code snippet to get the appdata path:

TCHAR szPath[MAX_PATH];
if (SUCCEEDED(SHGetFolderPath(NULL, CSIDL_APPDATA, NULL, 0, szPath)))
{
    //....
}

But the actual value of szPath is C:\Users\Admin\AppData\Roaming, not C:\Users\Test\AppData\Roaming that I wanted.

Anyone knows how to do that? Thanks in advance.

Community
  • 1
  • 1
little.ming
  • 13
  • 7
  • No, you can run as "Administrator" in any account. It doesn't switch to a different account. On many computers there is no specific account called "Administrator" and there is no folder called "c:\users\administrator" but you can still run as Administrator, meaning the program has elevated access. – Barmak Shemirani Apr 01 '16 at 07:22
  • @BarmakShemirani I had a typo. It's C:\Users\Admin\AppData\Roaming not c:\users\administrator. My administrator's account name is admin. – little.ming Apr 01 '16 at 07:38
  • 1
    There's nothing to fix. You're running the process in the context of the admin account, so that's the correct AppData path for that process. Using the test account's AppData folder while you're running as admin would cause problems. – Harry Johnston Apr 01 '16 at 07:41
  • You probably shouldn't be running "as administrator", why did you? – Harry Johnston Apr 01 '16 at 07:42
  • @HarryJohnston Because my project requires so, I have to run it as administrator:( Do you know some other way to get the current user app data path under this condition? – little.ming Apr 01 '16 at 07:46
  • 1
    It isn't impossible, but it is almost always the wrong thing to do. Why do you need the current user's AppData folder, if the process is actually running as another user? What are you going to use the AppData path for? (How is the end user going to run your program if they don't have administrator credentials?) – Harry Johnston Apr 01 '16 at 07:52
  • You can run a process as a different user, for example with `LogonUser` maybe that's what you are looking for. – Barmak Shemirani Apr 01 '16 at 07:58
  • My part of job is to write code to migrate data from a device to another device's any account, AppData is included @HarryJohnston – little.ming Apr 01 '16 at 08:03
  • That shouldn't require elevation, though. Looks like quetzalcoatl is on the right track. – Harry Johnston Apr 01 '16 at 08:12
  • Thanks, I'll try your solution:)@BarmakShemirani – little.ming Apr 01 '16 at 08:12
  • Because we are doing something on COM components, I'll try quetzalcoatl 's solutions. Thanks for your time:)@HarryJohnston – little.ming Apr 01 '16 at 08:14

1 Answers1

1

The root cause of your problem is running VS as "Admin" account. As long as you keep doing it, %AppData% will point to that account's appdata folder. No suprises.

So, you have to change your approach. Some options:

  1. you can remove the hardwired dependency on %APPDATA%. Don't do it automatically. Put that into some config file and read the path from there. You will be then able to run the app under any account and configure it to look at any path
  2. you can add flags to turn that config file on/off in debug/release modes, etc
  3. VS runs as Admin in elevated mode - ok, so use it to compile the app. Then run/debug/test your app under your normal account. VS can be running as user X and app can be running as user Y. Since X is Admin, VS will still be able to connect/debug Y's processes. Simplest example: stop using F5 to run&debug, use debug/attach-to and your the app manually
  4. most often, VS doesn't need to run a 'Admin'. More likely, it needs to run in elevated context. Make sure your account is in Administrator group/etc, then RunAs the VS as yourself with elevation on. If everything is ok, it will run with "admin rights" as your account then.
  5. why do you even need the VS to be elevated? It's not normal. Whoever tells you that, in 99.9% cases is wrong. Most common case when "VS needs to be elevated" is when someone works on COM components and uses COM autoregistration. You can't re/un-register a COM component without admin rights, so yeay go run VS as admin. Wrong. Write a small batch/exe/script that will un/register that component, mark it to require elevation, add it to pre/postbuild step or msbuild task, and VS can magically keep running at user level again

and so on.. there are many options, everything depends on what you are willing to change in your methodology..

regarding 4th one: try this thing - find a shortcut to 'Commandline' (cmd.exe) in your start menu. Right-click on it. You should see option "Run as administrator" (NOT "Run as other user..") Use it. Once console opens, write: echo %APPDATA% and check what it is. It should point to YOUR appdata, yet on the window title bar you should see Administrator:CommandPrompt warning info. Now write start cmd.exe. Another admin-console should pop up prooving that elevation propagates to child processes. Check APPDATA in the new console, it should still be yours. That was just a test.

If console worked and propagated elevation and env vars, then you should also be able to pick "Run as administrator" on the VisualStudio icon directly. And that's all.

quetzalcoatl
  • 32,194
  • 8
  • 68
  • 107
  • Thanks for your solution, I'll try them. We are doing something on COM components, that's why we need to elevate VS. – little.ming Apr 01 '16 at 08:09