Make explorer context menu registry entries platform specific to allow them to work also when both x86 and x64 are installed. The main menu has a " (x86)" appended to the main menu as well.
The symbol resolver was properly resolving the type to the class
definition, but that resolution was ignored at runtime because we used
the string instead of the ITypeName - the ITypeName kept the reference
to the class definition.
Fix#5661
Fix bug #5597: x86/x64 installer are uninstalling each other when installing either of them:
-Make x86 installer to be installed as an x86 component (-arch argument to candle.exe, which sets the `sys.BUILDARCH` variable)
-Make the UpgradeCode unique per platform
-Replace `var.ProductTargetArchitecture` variable with sys.BUILDARCH use to have only 1 variable for the architecture
-Additionally, the architecture was appended to the package name to be able to distinguish the installations.
# Conflicts:
# assets/Product.wxs
Make PowerShell Core reads group policy settings from different registry keys (Windows only) and the configuration files (both Windows and Unix).
- On Windows, move to different GPO registry keys.
- On both Windows and Unix, read GPO related settings from the configuration file `powershell.config.json`.
- On Windows, the policy settings in registry take precedence over the configuration file.
- Enable policy controlled logging and transcription on Unix.
Fix bug #5597: x86/x64 installer are uninstalling each other when installing either of them:
-Make x86 installer to be installed as an x86 component (-arch argument to candle.exe, which sets the `sys.BUILDARCH` variable)
-Make the UpgradeCode unique per platform
-Replace `var.ProductTargetArchitecture` variable with sys.BUILDARCH use to have only 1 variable for the architecture
-Additionally, the architecture was appended to the package name to be able to distinguish the installations.
Make PowerShell Core reads group policy settings from different registry keys (Windows only) and the configuration files (both Windows and Unix).
- On Windows, move to different GPO registry keys.
- On both Windows and Unix, read GPO related settings from the configuration file `powershell.config.json`.
- On Windows, the policy settings in registry take precedence over the configuration file.
- Enable policy controlled logging and transcription on Unix.
Move definition of Launch PowerShell checkbox to the top to allow toggling it using the spacebar (the Enter key already defaults to the Finish button).
Reuse product name variable.
Various SAL annotations were either incorrect or not backed up by code. This PR address these issues.
NOTE: By default, Start-BuildNativeWindowsBinaries does not enable code analysis and issues detected by SAL annotations are not reported. To identify these issues, run Start-BuildNativeWindowsBinaries to generate the solution and vcxproj files. Launch a Visual Studio developer prompt, cd to src\powershell-native and run msbuild manually.
> msbuild PowerShellNative.sln /p:RunCodeAnalysis=true /p:Configuration=RelWithDebInfo /p:Platform=x64
The following changes address all code analysis warnings:
- GetRegistryInfo in NativeMsh had incorrect out annotations, remove __opt
- Fix handling of various out parameters - check for non-null and initialize
- Update and Align SAL annotations for GetFormattedErrorMessage overloads
- Allow PluginException to accept NULL message.
Since Pester is not a submodule anymore, replace submodule example in git submodule docs/FAQ.md with the only leftover submodule src/libpsl-native/test/googletest
On windows, group policy settings from registry takes precedence over the configuration file.
If a policy is not defined in GP, then we query from configuration file.
Since Pester is not a submodule anymore, replace submodule example in git submodule docs/FAQ.md with the only leftover submodule src/libpsl-native/test/googletest
A new dialogue is added in the Windows installer to offer the option of adding explorer.exe context menus to open PowerShell in the current location as a normal shell or as administrator. The context menu entries are achiveven via registry entries and is available when right-clicking on:
- the background of explorer
- a folder in explorer
- a drive in explorer
- on the Desktop
Issue #4029 exposed two problems when failing to load libpsrpclient.
WSManAPIDataCommon.ctor was not identifying the binary that failed DLLImport; hindering diagnosability
PrioritySendDataCollection.Clear() would throw a NullReferenceException when called from the finalizer after an error path.
This change addresses both of the above:
Guard against null arrays in PrioritySendDataCollection.Clear() - called from finalizer in error paths.
Diagnosability: Log the DllNotFoundException in WSManAPIDataCommon ctor and also include it as the internal exception when throwing PSRemotingTransportException.
Update Restore-PSPester to include PR PowerShell/psl-pester#12 that fixesPowerShell/psl-pester#11 - unhandled exceptions in before/after bypasses Pester's enddescribe logic.
Update to the latest, while we are at it.
- Remove the unneeded base type;
- Rename 'ConfigPropertyAccessor' to 'PowerShellConfig';
- Move 'PowerShellConfig' to the namespace 'System.Management.Automation.Configuration'
Issue #4029 exposed two problems when failing to load libpsrpclient.
WSManAPIDataCommon.ctor was not identifying the binary that failed DLLImport; hindering diagnosability
PrioritySendDataCollection.Clear() would throw a NullReferenceException when called from the finalizer after an error path.
This change addresses both of the above:
Guard against null arrays in PrioritySendDataCollection.Clear() - called from finalizer in error paths.
Diagnosability: Log the DllNotFoundException in WSManAPIDataCommon ctor and also include it as the internal exception when throwing PSRemotingTransportException.
Update Restore-PSPester to include PR PowerShell/psl-pester#12 that fixesPowerShell/psl-pester#11 - unhandled exceptions in before/after bypasses Pester's enddescribe logic.
Update to the latest, while we are at it.
Before this PR, when a WiX compilation error occurs then an error is thrown, which appears in the log with details but the AppVeyor build itself is still marked as green.
This PR makes the console host also return an exit code of -1 when being run on AppVeyor so that it can then interpret it as a build failure and mark the build as red. It uses the fact that AppVeyor defines an environment variable named CI. Exiting is OK since the MSI build is the last step in CI and nothing happens after that.
The git history shows a test build that proves that this works if the installer was broken.
