This change updates ModuleIntrinsics.GetModulePath to handle the case where the Windows PowerShell module path is already in the environment's PSModulePath or when launched from a different version of PowerShell.
Previously, GetModulePath would append $PSHOME\Modules to the PSModulePath after removing the path for the launching version without considering the Windows PowerShell module path. The result, was the Windows PowerShell modules were found first and loaded incompatible modules; such as the built-in modules.
The change detects the Windows PowerShell module path and inserts $PSHOME\Modules path before it. The new test simulates launching from a different version of pwsh that has already added the Windows PowerShell module path.
Fixes#7679
Remove code from build.psm1 that save the modules to a versioned folder. For servicing reasons after release it is preferred and easier to not have the versioned folder so that we can directly replace modules that need to be serviced (MSI specifically makes it difficult to service a module if the folder path changes).
- Formatting file should be used for `MarkdownOptionInfo` object instead of the types file for adding script property.
- Downlevel windows consoles which do not support VT100 escape sequences should be handled gracefully.
- Add helpuri fwlink for cmdlets.
- Make `-Path` a positional parameter for `ConvertFrom-Markdown`
- make `-InputObject` a positional parameter for `Set-MarkdownOption`
- Add `%WINDIR%\System32\WindowsPowerShell\v1.0\Modules` (Windows PowerShell $PSHOME) to the end of the default PSCore 6 module path (i.e. the module path as initially set at startup).
- Cause an error to be thrown by `Import-Module` when a module with `CompatiblePSEditions` not containing `"Core"` is being loaded from the 'System32' module path.
- Suppress output of modules listed by `Get-Module -ListAvailable` from Windows PowerShell $PSHOME when `CompatiblePSEditions` does not contain `"Core"`.
- Introduce the `-SkipCompatibilityCheck` switch parameter on both `Import-Module` and `Get-Module` to respectively allow importing incompatible modules and listing incompatible modules.
- Adds a `PSEdition` column to the `PSModuleInfo` table view format.
- Ensures that completions are not given for incompatible modules on the System32 module path.
* [FEATURE] Allow Basic Auth over HTTPS
* WSManTransportManager.cs: Simplify HTTPS check
Update comment in test to refer to the right exception type.
* Disable test until limi crash fo selected connection error paths is fixed
* Use Hex format for defining the expected HRESULT
Dynamic (DLR) objects work in some places today, but not others. This change expands that support to ForEach-Object, Where-Object and the family of cmdlets that use 'MshExpression' (Select-Object, etc.).
This change addresses both wildcard and non-wildcard cases. In wildcard cases, it uses the existing support of generating PSDynamicMember objects for names returned by GetDynamicMemberNames.
In non-wildcard cases, a dynamic property access is attempted whether or not the name shows up in GetDynamicMemberNames, but a truly "blind" access is only attempted if we see that the base object is an IDMOP. If the dynamic access fails, you'll get the same or a similar error experience as before ("The property 'Blarg' cannot be found", or no error at all, depending on the cmdlet and the strict mode setting).
The included test coverage includes a stub for the.ForEach operator--once people are happy with this change, I can continue by adding support there.
This change should allegedly also have positive perf impact, though in actual perf testing, although it does seem ever-so-slightly faster, I found it difficult to measure much difference at all.
PowerShell serialization has a list of known PowerShell types. When an object is deserialized containing a known type it tries to deserialize the object to that specific type and throws an exception if it can't succeed. SemanticVersion only exists in PSCore6 so when remoting from Windows PowerShell or importing clixml generated from PSCore6 that contains SemanticVersion, it fails.
With this fix, it will be rehydrated as a "PSObject" with "Deseriealized.System.Management.Automation.SemanticVersion" in the 'TypeNames' in both Windows PowerShell and PowerShell Core.
Convert ShouldBeErrorId to Should -Throw -ErrorId in PowerShell tests.
Get rid of try { } catch { } formula to assert that errors were thrown.
Small fixes in tests to obey the new Pester -Parameter syntax.
* Build Update
- Change `TargetFramework` to `netcoreapp2.1` and removed unnecessary `RuntimeFrameworkVersion` from `PowerShell.Common.props`
- Update dotnet SDK to 2.1.300-rc1-008662
- Update `TypeGen` target in `Build.psm1` to work with 2.1
- Rename macOS runtime to `osx-x64` as the old build logic expects 10.12 and breaks running on 10.13 system.
- Remove `PackageReference` to `System.Memory` as it's part of dotnetcore 2.1
- Update search for `crossgen` executable to find the matching version
* Test Update
- Update test tools `WebListener` to latest `asp.net core`
- Marked `AuthHeader Redirect` tests as `Pending` due to change in CoreFX
The Test-Connection cmdlet works on Windows and Unix.
Implemented:
Ping
Continues Ping
Traceroute
Detect MTU size (seems don't work on Unix because of .Net Core issue)
Connect to TCP port
Not jet implemented:
I'm putting this off for the future.
Detect blackhole routers
PingPath
Additional considerations
As you can see in the tests .Net Core has issues in API implementation. As a result, some tests are skipped on Unix. There is also one issue on Windows. Related comments added to tests.
I'm going to open an issue(s) in CoreFX repo.
I think we should break the feedback into two parts:
scripting functionality
interactive functionality (display output)
Now I have implemented the output to the screen as the progress bar and as text (without ETS) - we have to decide what is best to use.
Clean up workflow logic in the module loading component.
Workflow module is not supported in PSCore.
Currently, Import-Module throws a terminating error when seeing .xaml modules. After the change, Import-Module throws a non-terminating error when seeing .xaml modules.
For a PropertyOnlyAdapter, the property may come from various sources, but methods, including parameterized properties, still come from DotNetAdapter. So, the binder can optimize on method calls for objects that map to a custom PropertyOnlyAdapter.
Some CI level 'Save-Help' tests were disabled in #2806 because HelpInfo URIs for powershell modules were broken (tracked by #2807). However, they were forgotten to be enabled when the URI issue was fixed. This PR reenables those tests.
Based on standard practices, we need to have a copyright and license notice at the top of each source file. Removed existing copyrights and updated/added copyright notices for .h, .cpp, .cs, .ps1, and .psm1 files.
Updated module manifests for consistency to have Author = "PowerShell" and Company = "Microsoft Corporation". Removed multiple line breaks.
Separate PR coming to update contribution document for new source files: #6140
Manually reviewed each change.
Fix#6073
* Test fixes and changes needed to support Pester 4.0.8
* Replace 'Should Contain' with new 'Should FileContentMatch' assertion
Explicitly check for string creation with write-output
* Use the current version of pester and install it in modulesDir
* Simplify logic for relative path test.
Multiple '..' is not needed for a relative path, a single one will do. Also, on multi-drive systems using split-path -noqualifier will probably do the wrong thing with regard to constructing a correct path.
Remove extraneous Should Not Throw test, if this throws, the test will fail, we don't need to explicitly assert the not throw
* In some environments it is possible that computer name is 'localhost', so that should be allowed
* [feature] Add link for migrating tests from Pester v3 to v4
Fix up capitalization and white space issues
Change one test to check FullyQualifiedErrorId rather than just `Should Throw`
* [feature] update invoke-item test to handle the case where multiple notepad processes are running
* Fix spelling issue with Pester 4x, calling it Pester 4 should be sufficient
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.
