There are cases like using PowerShell via Puppet where the account being
used does not have a home directory. Updated PowerShell to use a process
specific temporary directory if HOME, CONFIG, CACHE, and DATA directories
are not available. Temporary directory is removed when last runspace
is disposed.
- Removed the -TimeoutSec option and modified the expected Error to be consistent across platforms.
- Changed the port of the phony proxy to 9 which is reserved for the Discard Protocol. So even if the system is listening, it's supposed to discard that TCP request (UDP may use it for Wake-on-Lan, but doesn't affect this).
* Help was incorrectly returning multiple instances of the same help file if it existed under a culture path and the parent was in the search path as well
* updated test to use generated help file rather than an actual one
* Fixed test to have module in $pshome path and casing of en-US culture
Related #3238
1. Add autoload for test modules
2. Move TestHostCS.psm1 to 'test\tools\Modules\' folder
3. Remove explicit load TestHostCS.psm1 from test files
- FullCLR build is disabled in this change.
- FullCLR build related functionalities in `build.psm1` and `AppVeyor.psm1` are disabled. They are not cleaned up from `build.psm1` and `AppVeyor.psm1` yet. We need to adopt .NET Core 2.0 to verify the portable module concept, and if that works well, we will remove the Windows PowerShell source code and clean up our scripts.
- `dnxcore50` and `portable-net5+win8` target framework monikers are removed.
- Dependency on `Microsoft.NETCore.Portable.Compatibility` is removed. It's not necessary, but it may come back when we work on supporting the `portable module`. Its necessity can be reviewed at that time.
- I didn't spend the time to try building powershell in Visual Studio 2017. We should have a separate issue for that. It's tracked by #3400
The `TypeCatalogParser` project is replaced by a MSBuild target to gather the dependency information.
Due to .NET Core SDK issue [#1021](https://github.com/dotnet/sdk/issues/1021), our meta-package project `Microsoft.PowerShell.SDK` starts to generate an empty assembly during the build and that results in an empty assembly `Microsoft.PowerShell.SDK.dll` appear in `publish` folder and in `.deps.json` file. We cannot simply remove the assembly because it's now part of the TPA, and removing it will cause powershell to crash at startup. We have to live with this empty assembly until that .NET Core SDK issue is fixed. It's tracked by #3401.
* Make Get-ComputerInfo tests handle the case of the root\Microsoft\Windows\DeviceGuard namespace not found on the test machine.
Catch CIM exceptions, but don't look specifically for namespace-not-found
* Update Get-ComputerInfo test to properly test DeviceGuard items.
Our assembly cache contains assemblies that are explicitly loaded by powershell egine, such as via module loading or the assembly entries from InitialSessionState. We should search it before searching all loaded assemblies to give preference to resolve a type against the assemblies contained in the cache, so that in case there is a conflict, we might have a preferred assembly to use for a type resolution.
Changes:
- Search from context.AssemblyCache.Values before search from all loaded assemblies.
- Skip assemblies that we already searched and found no matching type.
- Skip checking PS types kept in the scope and type accelerators when it's not necessary.
* PowerShell transcripts should include the configuration name in the transcript header
* adding test case for PowerShell transcripts should include the configuration name in the transcript header #2890
* corrected use of PSModulePath casing to be consistent with Windows PowerShell
addresses #3227
* addressing review feedback
make "PSModulePath" into const
fixed some test workarounds due to failures for external reasons that wasn't meant to be checked in
* addressing review feedback
make "PSModulePath" into const
fixed some test workarounds due to failures for external reasons that wasn't meant to be checked in
* Refactoring ParsePathCommand.cs (SplitPathCommand) for readability
- Using auto properties when no when there is no logic in getter/setter
- Removing unused code
- Removing redundant qualifiers
- Removing Redundant initializers
* Add -Extension and -Leafbase switches to Split-Path cmdlet
- Extension and LeafBase are specializations of Leaf, and uses System.IO.Path.GetExtension and System.IO.Path.GetFilenameWithoutExtension to extract parts from the Leaf
* Adding tests for Split-Path -LeafBase and Split-Path -Extension
Resolving #3242
At this point, user account is created even if user attributes assignment
(like setting password) fails. The cmdlet throws a
non-terminating error but ends up creating the user. This behavior is
confusing. As per the changes, the localuser account will be rolled back
in case of failure in user attributes assignment.
Two updates with this PR:
- reclassified automounted drives tests to be 'Feature' instead of 'CI' because this is more accurate;
- fixed failures in tests setup caused by "subst.exe" native utility having problems running as child process of powershell process tree run under "runas.exe /trustlevel:0x20000" (in Start-UnelevatedProcess in build.psm1).
* adds parameter sets to web cmdlets to allow for standard and non-standard method verbs
* add CoreCLI implementation
* Adds CM alias and notnullempty for CustomMethod parameter
* Add tests for Invoke-[WebRequest|RestMethod] CustomMethod parameter
* Fix webcmdlet tests - incorrect parameter name
XDG profile directory creation can fail for accounts that do not have home directories.
The module analysis was trying to persist it's cache in an XDG profile directory.
The cache is less critical than it once was, so it's reasonable to not cache if there is no good place to do so.
Fixes#3011
Changed hard coded Windows directory separator and resolved path so the slashes are correct.
Throw if resolving file path returns more than one result
Fixes#2610
These changes provide the ability to debug remote running scripts started with the Invoke-Command cmdlet. The design is event based and provides new public events that allow subscribers to be notified when an Invoke-Command remote session is ready for debugging. Since Invoke-Command allows running scripts on multiple targets at once (fan-out) the notification event is raised for each remote session as it becomes ready for debugging. The subscriber to these events will be a script debugger implementation (such as PowerShell console, ISE, or VSCode) and will handle all debugging details such as simultaneously debugging multiple remote sessions at once in separate windows.
But these changes also include an internal implementation which is used by default if host debuggers don't want to handle the debugging details. This internal implementation is what PowerShell console, ISE uses so they can have this new behavior without having to modify their debugger implementations. The internal implementation serializes each remote session of Invoke-Command so that they can be debugged one at a time. The remote session debugger is "pushed" onto the internal debugger stack so that debugging transitions to the remote session. Existing debugging commands work so that the "quit" debugging command will stop the current remote session script from running and allow the next remote session to be debugged. Similarly the "continue" debugging command allows the script to continue running outside step mode and again go to the next remote session for debugging. The "stepout" debugging command steps out of all Invoke-Command remote sessions and lets the script continue to run for each remote session in parallel as they are normally run.
The purpose of Invoke-Command step-in remote debugging is allow seamless debugging of a local script that calls Invoke-Command on remote targets. But there is also a new Invoke-Command "-RemoteDebug" parameter that lets you Invoke-Command on the command line and have it drop directly into the debugger.
An example from the PowerShell command line looks like this:
```
PS C:\> C:\TestICM.ps1
Entering debug mode. Use h or ? for help.
Hit Command breakpoint on 'Invoke-Command'
At C:\TestICM.ps1:2 char:1
+ Invoke-Command -cn $computerName,paulhig-3 -File c:\LinuxScript.ps1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[DBG]: PS C:\>> list
1: $computerName = "localhost"
2:* Invoke-Command -cn $computerName,paulhig-3 -File c:\LinuxScript.ps1
3: "Test Complete!"
[DBG]: PS C:\>> stepin
At line:1 char:1
+ Write-Output "Running script on Linux!"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[paulhig-3]:[DBG]: [Process:14072]: [Runspace5]: PS C:\Users\paulhi\Documents>
```
Notice that the debugger "stepin" command transitioned from local script debugging to debugging the remote session on computer "paulhig-3", as can be seen by the change in the debugger prompt.
You can also do this from the command line to drop directly into the debugger
```
Invoke-Command -cn localhost -Script $scriptblock -RemoteDebug
```
These changes also remove an old behavior that was incompatible with this new step-in feature. Previously if a remote session running script hit a break point it would stop in the debugger and go to the "disconnected session" state. This was to allow the user to reconnect using Enter-PSSession and then interactively debug the remote session script. This behavior has been removed and now the user needs to attach a debugger using the newer Debug-Runspace cmdlet.
* Prettier formatting for ConvertTo-Json output. #2736
This change standardizes JSON output to example given, as well as
codemaid and online lint tools.
Sample object used for testing:
@{
foo = @{
first = 'a'
second = 'bbbbbbbb'
}
barbarbarbar = @{
first = 'a'
second = 'bbbbbbbb'
NestedArray = @(
'Test3'
'Test4'
'Test5'
3
4
)
NestedObject = @{
MoreObject = 'AnotherObject'
TestBool = $true
}
}
array = @(
'Thing1'
'Thing2'
)
dan = 15
} | ConvertTo-Json
* Updated CoreCLR implementation to use NewtonSoft Indented Formatting
I did not change the FullCLR behavior, I was not sure if you meant to
revert my changes or to leave it as is in the current pull request.
* Added tests that validate pretty Json output.
Not sure if there is a better thought on how to implement these. The
first two fail against current master, but succeed once this PR is
applied. Third test is successful prior and post this PR.
* Moved tests and removed extraneous file.
Moved pretty/compressed json tests from standalone file into the
existing ConvertTo-Json test file.
* Updated tests for cross-platform support
* Implement -version parameter in console host (address part of https://github.com/PowerShell/PowerShell/issues/1084)
This does not support providing a specific version to run, but
like most other *nix commands, -version will now return the version
of the PowerShell Engine. 'powershell' is prepended to the output to
match other *nix commands. We are using gitcommitid which includes more
info about the build.