Remoting relies on Windows native crypto APIs to pass a secure string. Of course these APIs don't work on non-Windows. However, the remoting code does not expect this to fail so ends up in a hang waiting for an event that never happens.
Have not figured out how to return an error to the user in the case `Get-Credential` is called within a PSSession. Currently it just quietly closes the remote connection. @PaulHigin can you give a pointer to where this code would exist? Debugging the current code, it has a bunch of error handlers which just result in the pssession being closed and not sure where throwing is appropriate.
Fix https://github.com/PowerShell/PowerShell/issues/8723
## PR Context
Fix is to provide implementations of the Win32 native pinvoke apis that throw an exception. The reason to do it this way is that there's a bunch of code that calls some of the APIs of the wrapper .Net class to setup structures that eventually get passed to the win32 api. Throwing in the managed class causes other things to fail early that should work on non-Windows.
Fix for #6741 Allow .exe files to be used as binary modules. Basically anywhere a .dll could be used with modules, you can now use a .exe file. Also did a little clean up, replacing constant strings with the StringLiteral values instead.
Major changes are:
- Make all commands return 'ConfirmImpact.None' if `SupportsShouldProcess` is not set to `true`.
- Update some cmdlets to explicitly use `ConfirmImpact.Low`.
- Update `DefaultCommands.Tests.ps1` to test for 'ConfirmImpact' level.
Instantiating a new MediaTypeHeaderValue object fails when the -ContentType parameter includes a charset such as application/json; charset=utf-8. This makes it impossible to set the content encoding on web requests. Moving to Parse() ensures we actually get a proper MediaTypeHeaderValue when the charset is present, thus allowing users to set their request encoding via proper -ContentType values.
* Improve check for developer mode by checking minimum required build number
The test would fail if the developer mode is enabled but the machine has an older build than the minimum required build.
The change adds a check for the build version in the test.
* Update test/powershell/Modules/Microsoft.PowerShell.Management/New-Item.Tests.ps1
We have the public API `JsonObject.ConvertFromJson` to convert from JSON string in the PowerShell context. It would be good to have a public API for conversion to JSON. This PR refactors the `ConvertTo-Json` cmdlet to move the core implementation to `JsonObject.ConvertToJson`, and make `ConvertTo-Json` call that public method.
This would help the Azure Function PowerShell worker. Currently, we depends on [calling the cmdlet](729710d259/src/PowerShell/PowerShellManager.cs (L198-L205)) to convert object to JSON which is expensive. Once we have the public method `JsonObject.ConvertToJson` exposed, we can call the API directly to avoid a command invocation.
Web Cmdlets will no longer forcibly remove Expect: 100-continue from web requests.
This was a legacy setting that needed to be there because of platform differences that have since been resolved in CoreFX.
Fix#8028
This change adds support for specifying the underlying type for an enum:
```powershell
enum MyEnum : long
{
A = 0x0FFFFFFFFFFFFFFF
B
}
# or
enum MyByte : byte
{
A = 0x01
B = 0x02
C = 0x03
D
}
```
One reported case where during applocker policy check, the test script that is created cannot be deleted because something else (malware scanner?) has a lock on the file. This results in an exception being thrown in finally block which ultimately causes PowerShell to crash due to the unhandled exception. Fix is to wrap the deletion in the finally block with try..catch and ignore any exceptions and leave the temp file.
TFS:20156282
