Elevate Permissions to Visual Studio For Post-Build Event Batch Script

Question

I have a batch file that copies a directory to a new location, creates 2 other .bat files, 2 .json files, and Inserts Registry Keys . When running the batch script for the command line, I get no errors and all desired outcomes. While running it from the post-build event command-line, I get no errors , but I'm missing the Registry entries. Co-worker suggested that this could be due to Visual Studio not having Admin permissions whereas the command line can. My question is: is there a way (without running Visual Studio as an admin) to elevate permissions for a post-build event? If you're wondering why not just run VS as admin, it's because this solution is shared via TFS, and not all my co-workers will know to run their instance of VS as admin for this one particular solution. I've Googled away with nothing to show for it. Thanks in advance for help! Here's the Post-build event command line I'm using. Again I know it works... it just doesn't plop the Registry values. CMD does. PS. Using VS 2013 on Windows 7

if $(ConfigurationName) == Debug call "$(ProjectDir)BatchFiles\DebugHelper.bat" "$(TargetDir)" C:\CEC\Batch\Test\

Answer 1

This is from Windows SDK about redirection (there is also reflected and shared)

Registry Redirector

The registry redirector isolates 32-bit and 64-bit applications by providing separate logical views of key portions of the registry on WOW64. The registry redirector intercepts 32-bit registry calls to each logical registry view and maps them to the corresponding physical registry location. The redirection process is transparent to the application. Therefore, a 32-bit application can access registry data as if it were running on 32-bit Windows even if the data is stored in a different location on 64-bit Windows.

Redirection is enabled for the following registry keys:

HKEY_LOCAL_MACHINE\Software 
HKEY_USERS\*\Software\Classes 
HKEY_USERS\*_Classes 
Note  * indicates a match for all user security IDs (SID).

The following scenario illustrates the use of these logical views:

A 32-bit application checks for the existance of the following registry key: HKEY_LOCAL_MACHINE\\Software\\Hello. If the key does not exist, it creates it with a default value of "Hello 32-bit world"; otherwise, it reads and displays the value. The same application is modified to write "Hello 64-bit world" instead of "Hello 32-bit world" and recompiled as a 64-bit application.

When the 32-bit application is run on 64-bit Windows, it displays "Hello 32-bit world". When the 64-bit application is run, it displays "Hello 64-bit world". Both applications call the same registry functions with the same predefined handle and the same key name; the difference is that each application operates on its logical view of registry, and each view is mapped to a separate physical location of the registry, which keeps both versions of the string intact.

To help applications that write REG_EXPAND_SZ keys containing %ProgramFiles% to the registry, WOW64 intercepts these writes and replaces them with "%ProgramFiles(x86)%". This environment variable is defined for all processes. For example, if the Program Files directory is on the C drive, then "%ProgramFiles(x86)%" expands to "C:\\Program Files (x86)".

To enable application interoperability through COM and other mechanisms, WOW64 uses registry reflection, which copies specific registry keys and values between the two registry views to keep them in synch. The reflector is intelligent and copies COM activation data for Local servers between the views, but not in-process data, because 32/64 in-process data mixing is not permitted on 64-bit Windows.

What to do

In a program

KEY_WOW64_64KEY 0x0100 Access a 64-bit key from either a 32-bit or 64-bit application.
Windows 2000:  This flag is not supported. 

KEY_WOW64_32KEY 0x0200 Access a 32-bit key from either a 32-bit or 64-bit application.
Windows 2000:  This flag is not supported. 

From command prompt see reg flags /? allowing your key to opt out of redirection.

And a reminder that UAC also may be virtualising it. As it redirects some writes to HKLM to HKCU. Giving permission for users to write to your key will overcome that.