Removing Common.Native.targets - to avoid increasing build complexity repo with native projects will have their own target that generates version.h file
* Adding an MSBuild target file that generates a header containing file and product versions which will be used in .rc files in native projects across all repos.
Note that keeping header generation in MSBuild is cleaner than generating it in a .shade file since the entire project is being built within a single build subsystem and therefore you can build the project directly (i.e. just with MSBuild) without having to do it with Sake (if the file did not exist)
* Updating native-compile target in _k-standard-goals.shade to pass version numbers.
Fixes: https://github.com/aspnet/DataProtection/issues/73
On IIS where there is no user profile, the code tries to always read the 32bit registry view irrespective of the bitness of the worker process. So in case of 64 bit app pools the registry key is null so it falls back to in memory ephemeral repository. On 32 bit app pool it can find an appropriate registry key, but the keyRepositoryDescriptor is not populated resulting in a null reference exception.
Current behavior:
X86 throws
X64 falls back to in memory ephemeral
With fix:
Both X86 and X64 will use DPAPI.
Fixes: https://github.com/aspnet/DataProtection/issues/73
On IIS where there is no user profile, the code tries to always read the 32bit registry view irrespective of the bitness of the worker process. So in case of 64 bit app pools the registry key is null so it falls back to in memory ephemeral repository. On 32 bit app pool it can find an appropriate registry key, but the keyRepositoryDescriptor is not populated resulting in a null reference exception.
Current behavior:
X86 throws
X64 falls back to in memory ephemeral
With fix:
Both X86 and X64 will use DPAPI.
N. Taylor Mullen
moozzyk
Troy Dai
Pranav K
Brennan
anurse
Chris Ross
Matt Ellis
Hao Kung
Kiran Challa
Wei Wang
Doug Bunting
Victor Hurdugaci
Praburaj