* Implement location history feature for Set-Location.
This makes it possible to go back to the last directory using 'cd -',
which is exactly the same syntax as on Linux shells.
* Use an existing stack implementation instead of relying on an environment variable and move logic for 'cd -' into the internal class of SessionState.Path.SetLocation
Keep the (additional) setting of an environment for Unix system in case of mixed usage of cd and Set-Location to provide consistency.
* Use a bounded stack with a limit of 1000 and adapt tests.
Remove setting environment variable on Linux as discussed in PR.
* Fix test: use get-location explicitly to avoid subtle difference in the path string (e.g. an additional slash at the end)
Make syntax to .net call of environment consistent with surrounding code
* Move initialization of _workingLocationHistoryStack into constructor of SessionStateInternal and set the limit to 20 as discussed in PR 5051.
* Make new BoundedStack class in engine utils internal
Closes#6944
Following PR #6945, further, reduce the total build time (without any disadvantages) by around 5 minutes by making sure there is a more even split between the 2 build jobs (the 2nd build job used to be much shorter).
Therefore this PR moves also the xUnit and Pester-Admin tests into the 2nd build job. If it is a daily/feature test commit, then the feature tests will also happen (only) in the 2nd build job. Because both jobs now run tests, the failfast option was removed. The final question from my side is whether running tests in 2 build jobs is OK for the daily build, which uploads code coverage results?
The time to wait for the AppVeyor build results is now 15 +/- 2 minutes, which is a huge improvement to what used to be around 28 minutes before the build matrix was introduced.
Update links that contain 'en-us' culture to remove 'en-us' culture (if possible) and in some cases update to newer re-directed link to docs.microsoft.com
* Fix broken installation links in README.md
* fix remaining broken links due to removal of breakingchanges and knownissues docs
* Remove en-us culture from docs links in readme
* Remove last en-us culture link from issue template
Related: #6944
Reduce PR build time by 5 minutes by:
Having Packaging as a separate build job in a matrix -> runs in parallel in PR builds because the Microsoft account is a paid account that allows that (at no additional costs)
Not caching the dotnet folder anymore, which is too large and the overhead of zipping/unzipping/upload/download does not pay off (and fails in forked builds that are on a free AppVeyor account due to the size).
Setting the environment variable DOTNET_SKIP_FIRST_TIME_EXPERIENCE to 1 because the initialization of the dotnet CLI cache (1 minute) does not pay off for the whole build.
The total build time of builds on a fork that is on a free AppVeyor account and therefore does not have parallelism, remains the same due to the time saving of redundant caching.
This is just a simple example of what we can easily achieve, we could continue this pattern and split the test runs as per the referenced issue to bring PR builds down to 10 minutes (but this will incur an increase for fork builds on free AppVeyor accounts)
* Perform JumpList creation in background thread to improve performance when pwsh owns the window (i.e. when the Jumplist has to be created)
* Move JumpList creation to a later stage to allow for more code that might make it exit earlier as suggested in PR review by @iSazonov
Closes#6649
This is a port of existing C++ Windows PowerShell code from MainEntry.cpp
Some of the code has been copied and minified from the WindowsApiPack.
The code is not compiled for Linux (not sure also another condition is needed for Windows on ARM?).
The code checks if the PowerShell process has a window handle by checking the startupinfo and only then tries to populate the list (and also checks if there is a slot available in the jumplist).
Tested on Windows 10 1803, jumpLists have been supported in Windows since Windows 7, which matches what PowerShell Core supports.
Fixes#6590 by adding registry keys to support the existing explorer context menu also when being inside a library folder. It follows the existing pattern that was already applied to special cases such as drives, Desktop, etc.
Manually Tested on Win 10 1709
Thanks to @mklement0 for triaging the issue and already researching the required registry key (he should also be included in the release notes)
- Fixes issue #4634 by throwing a terminating error as agreed.
- Makes the command not rely on the presence of the TEMP environment variable to get path to temp directory and use the .Net method Path.GetTempPath() instead.
- Catch exception more specific as given by the documentation
- Improve existing test.
PR 6043 broke the installer (issue #6095). To prevent this from happening in the future, add a smoke test that installs the msi in appveyor build and make build fail if installation failed.
It uses the exit code to determine the success. The reason why it does not fail in the current state is because as I pointed out here, the failing custom action is not returning its exit code.
This is the continuation of PR 5499 that had to be abandoned due to a fatal merge conflict and I did not want to risk accidentally reverting recent fixes.
Remove unnecessary/unused default for productGuid because it always gets a new Guid when being called from Start-PSPackage
Add defaults for required files but also add extra path validation attribute
Rename ProductGuid to ProductCode
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.
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
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.
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.
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
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
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.
When changing the WiX installer locally and rebuilding the MSI one can get into the terrible situation whereby a code change does not get compiled into the new MSI.
This PR fixes the root cause of it, which is due to temporary WiX files that are created but not deleted after compilation and WiX then somehow decides to not recompile properly.
I also removed redundant parenthesis of surrounding code.
This resolves issue #5391, which is tagged with 6.0.0-GA, therefore this should help with getting pwsh out of the door in January.
It removes PerformWSManPluginReportCompletion as stated in the issue and its associated class member g_pPluginContext, which is now unused as well.
The best reviewer is probably @mirichmo , who raised the initial issue with very helpful descriptions or @dantraMSFT who is currently assigned to the issue.
* Disambiguate icon for daily builds on Windows.
Some code had to be borrowed from build.psm1 because this script has to be self contained in case it gets executed by only downloading this file via the published download link https://twitter.com/Steve_MSFT/status/930585082451992576
This resolves issue #5391, which is tagged with 6.0.0-GA, therefore this should help with getting pwsh out of the door in January.
It removes PerformWSManPluginReportCompletion as stated in the issue and its associated class member g_pPluginContext, which is now unused as well.
The best reviewer is probably @mirichmo , who raised the initial issue with very helpful descriptions or @dantraMSFT who is currently assigned to the issue.
* Disambiguate icon for daily builds on Windows.
Some code had to be borrowed from build.psm1 because this script has to be self contained in case it gets executed by only downloading this file via the published download link https://twitter.com/Steve_MSFT/status/930585082451992576
Replace the static `powershell.inc` filename with a name based on the current RID, so that the build doesn't confuse when running in the same local repository on WSL.
Address #3623.
Implementation symmetric to traditional code path that returns a PSCustomObject. Code is shared on the top level but 2 low level methods were difficult to share, therefore 2 separate but similar methods were created for HashTables.
All existing tests related to this change were adapted to also test against this new switch and were slightly improved.
-AsHashtable is an existing pattern used in Group-Object
* A simple and minimal fix of 4665 to check for the Visual Studio C++ 2015 redistributables. Note that this is specific to 2015 (vcruntime140.dll refers to the Visual Studio version 14.0, which maps to Visual Studio 2015).
A previous check registry check of 'SOFTWARE\Microsoft\DevDiv\VC\Servicing\14.0\RuntimeMinimum' failed because when the redistributables are installed via Windows update (which does not use MSI), then the registry entry did not get populated.
The 'Pending' attribute was removed from existing tests since the download links are now present again and the tests were improved using Pester TestCases.
* Fixed typo spotted in code review of PR 4745
* Remove DirectorySearch Id duplication by defining it once and referencing according to this special trick in the official WiX documentation here: http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/directorysearchref.html
Renamed property values as suggested.
* Remove replacements of HTTPS with HTTP, i.e. test against exact link. Use -UseBasicParsing switch with the hope of not having failures in the CI environment.
Added comment why there is no assertion about the StatusCode.
* Replace download links with link to pre-requisites page as suggested in PR 4745 because this page is easier to update
* Compilation error CNDL0012 fix: WiX does not allow lowercase characters for file search property Ids because due to them being used for a search property means that they must be public, hence lowercase is not allowed.
* Make the build output the WiX compilation log if it failed.
Before it was not outputting it not at all because the build output is an array that was piped directly to 'Write-Verbose' instead of converting it to a string using 'Out-String'
Because the WiX log is usually quite verbose (around 250 lines), the log is only shown if there must have been a compilation error due to the missing MSI
* PR 4831: Use -Verbose option on Write-Verbose to force output in build as suggested in review.
* #4458 MSI installer checks that the Windows C Runtime and VS Studio 2015 C++ redistributables are present and returns error message if not.
Includes tests to check that the Wix file contains the download URLs and those URLs are not dead.
- Fix PSScriptAnalyzer warnings of type PSAvoidUsingCmdletAliases for 'ForEach-Object' (alias is '%' or 'foreach')
- Fix PSScriptAnalyzer warnings of type PSAvoidUsingCmdletAliases for 'Where-Object' (alias is '?' or 'where')
- Fix PSScriptAnalyzer warnings of type PSAvoidUsingCmdletAliases for 'Select-Object' (alias is 'select')
- Fix PSScriptAnalyzer warnings of type PSPossibleIncorrectComparisonWithNull. Essentially, $null has to be on the left-hand side when using it for comparison.
- A Test in ParameterBinding.Tests.ps1 needed adapting as this test used to rely on the wrong null comparison
- Replace a subset of tests of kind '($object -eq $null) | Should Be $true' with '$object | Should Be $null'
Added a checkbox (unchecked by default) to the last dialogue of the Windows installer to provide the option of opening PowerShell because that's what most people want to do if they installed PowerShell.
Christoph Bergmeister
