c++ how to get %AppData% path under non-administrator account and running VS2013 as Administrator

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.

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.