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.
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
After parsing `if () { }`, new lines are skipped in order to see if either `elseif` or `else` is present. When neither is present, we should resync back to the pointer before skipping those possibly available new lines, so that the new line tokens can be utilized by the subsequent parsing.
The cleanup is coming from a code review to cleanup psl. Here we clean up the side branch of the code that will allow later to clean up a branch which uses psl.
- IO.FileInfo does not make system calls in constructor. So we can create the object and then use the required attributes without direct call IO.FileInfo.GetAttributes() ( SafeGetFileAttributes() ). This allow us to exclude some p/invoke calls in our code in later cleanups. Also we get unified code for both Windows and Unix.
- Remove SafeGetFileAttributes() and WinSafeGetFileAttributes(). Currently .Net Core support file attributes on all platforms in fastest way and we can remove our workaround. We get a regression in rare case (for files like pagefile.sys). Fix is ready in CoreFX, we get it in 2.1.1. I suggest ignore the regression because this is a very-very rare situation (Get-ChildItem c:\pagefile.sys -Hidden). The .Net Core team was not even able to create an artificial test for such files and uses a real pagefile.sys file for the test. Also the enumeration is still working (dir c:\ -hidden).
- Re-add test which we lost in #4050. The test is pending because of the regression.
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.
Refactor code to make it easier to maintain and a little faster. Changes are as follows:
1. Support finding a matching signature with variance. But make PowerShell prefer exact match over a match with variance.
2. The metadata signatures in `PSMethod<..>` are generated based on the array of method overloads in `MethodCacheEntry.MethodInformationStructures`, in the exact same order. So in `LanguagePrimitive.ConvertViaParseMethod`, when we try to figure out if there is a match using the metadata signatures in `PSMethod<..>`, we can get the index of the matching signature, and the same index should locate the matching method in `MethodCacheEntry.MethodInformationStructures`. Therefore, we don't need to compare signatures again in the actual conversion method, and instead, we can just leverage the index we found when figuring out the conversion in `ConvertViaParseMethod`.
- This gets rid of the reflection call `GetMethod("Invoke")` and the subsequent signature comparisons in the final conversion method.
- Also, when comparing signatures using `PSMethod<..>` in `ConvertViaParseMethod`, we can just use the generic argument types of each `Func<..>` metadata type, instead of calling `GetMethod("Invoke")` and then `GetParameters()`. This makes the code for comparing signatures simpler (the type `SignatureComparator`).
- Move `MatchesPSMethodProjectedType` from `PSMemberInfo.cs` to the type `SignatureComparator` in `LanguagePrimitives.cs`, as it's closely related to the signature comparison. Also, renamed it to `ProjectedTypeMatchesTargetType`.
- These changes make PSMethod-to-Delegate conversion a little faster, but no big improvement, as the true bottleneck probably is in delegate creation(?). Actually, the performance of this conversion is not critical at all at this moment because this feature should rarely be used in any hot script path. So this exercise is mainly for fun.
3. Remove `PSEnum<T>`. We can directly use enum types when constructing the metadata type `Func<..>`.
4. Remove the code that generates metadata signatures for generic method definitions (call `MakeGenericMethod` with fake types like `GenericType0`, `GenericType1`). This is because:
- We don't support convert generic method to delegate today, so may be better not spending time on preparing the metadata signature types for those methods.
- When the day comes that we need to support it, it's better to use generic argument types directly to construct the `Func<..>` metadata types. I left comments in `GetMethodGroupType` method in `PSMemberInfo.cs` to explain why that approach is better.
closes#6728
Breaking change approved in #6728
This PR switches the logic of when the Web Cmdlets handle redirects when the Authorization header is present. .NET Core 2.1 no longer sends the Authorization header by default (dotnet/corefx#26864). however, we introduced the ability to do so leveraging the previous default behavior through the use of the -PreserveAuthorizationOnRedirect switch.
This PR also corrects a bug introduced 6.0.0 where certain redirect types redirect from POST to GET were set which should have passed through POST to POST and some were improperly passing through POST to POST which should have been doing POST to GET. This correction is a breaking change. It was made apparent as now the redirection behavior is being managed by CoreFX which is doing the correct behavior, tests were added for both when CoreFX and the Web Cmdlets manage redirection.
This regression was introduced by #6523, in `PSModuleInfo.cs`. A circular nested module check was removed because the comment there suggested it happens only with a deprecated workflow module. This causes a `StackOverflow` exception when running into circular nested modules.
Circular nested modules could happen for a module that is not well structured. For example, the module folder `test` contains two files: `test.psd1` and `test.psm1`, and `test.psd1` has the following content:
@{ ModuleVersion = '0.0.1'; RootModule = 'test'; NestedModules = @('test') }
The same value `test` is put in both RootModule and NestedModule, which will end up with a module whose nested module points to itself.
There are two changes in this PR:
1. Add back the check for circular nested modules in `PSModuleInfo.cs`.
2. Remove a wrong `Dbg.Assert` in `ModuleCmdletBase.cs` and two checks before it.
- For the assertion `Dbg.Assert(newManifestInfo.SessionState == ss`, when facing the example above, the nested module will first be loaded with a different session state, and then when trying to load the root module, the same loaded nested module will be reused for it. So 'newManifestInfo.SessionState' is not `ss`. The assertion will fail in that case.
- For the two checks before the assertion, they are not needed anymore based on the comments there.
* 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
Fix Select-Object.Tests.ps1 which might fail for Unix OS.
In the test, the processes which name matches i* are selected and it checks if there is non zero number of these processes. The test assumes that there is always at least one process, probably `init` - idle, but on Unix idle process does not have the name and hence the test might fail
- Can compile a source from strings (TypeDefinition and MemberDefinition).
- Can compile from files.
- Can compile only to a file (without loading the produced assembly).
- Do not recompile and don't reload if the sources have not changed.
- Implement `-IgnoreWarnings` to not treat warnings as errors. By default, the cmdlet considers warnings as errors.
- Add VisualBasic support.
- Add new `-CompilerOptions` parameter to allow setting Roslyn command line parameters including:
- Parser options.
- Compile options.
- Emit options.
**ATTENTION:** The `CompilerOptions` can be specified along with other options like `-OutputAssembly`, `-Language` and `-IgnoreWarnings`. The explicit setting parameters will take precedence over the same settings specified in `-CompileOptions`.
See docs about the compiler options:
https://github.com/dotnet/roslyn/blob/master/docs/compilers/CSharp/CommandLine.mdhttps://github.com/dotnet/roslyn/blob/master/docs/compilers/Visual%20Basic/CommandLine.md
**ATTENTION:** `-OutputType` default is `Library`. If `-OutputType` is absent the `-OutputType` default overlaps a value in `CompileOptions`. In other words output type ("target" ot "t" in command line) is always ignored in `CompileOptions`. We have to use `-OutputType` to set an output type.
- For ConsoleHosts tests, the test is validating error condition, but did not redirect stderr to stdout so the output isn't captured and thus an empty string failing the assertion.
- For SSHConnectionInfo API tests, it's calling a constructor that got overwritten with a new parameter. Fix is to put back that public API and overload it with a new one.
These changes port Windows PowerShell support for Applocker and DeviceGuard User Mode Code Integrity (UMCI) to PSCore6. Windows PowerShell uses public APIs to determine if a system is in locked down mode via AppLocker or DeviceGuard, and automatically runs in constrained language mode. For more information about PowerShell constrained language, see: https://blogs.msdn.microsoft.com/powershell/2017/11/02/powershell-constrained-language-mode/
This support for application whitelisting has mostly existed in PSCore6, but the primary APIs were stubbed out in CorePSStub.cs because they relied on Windows only DeviceGuard (wldp.dll) and AppLocker (Safer APIs) public APIs. These changes re-implement PowerShell lock down APIs on PSCore6 for Windows platforms only. The AppLocker and DeviceGuard public APIs are currently only implemented in Windows OSes and are not supported on Linux or MacOS platforms.
Tests have also been ported to PSCore6 and run only for Windows platforms.
Create the default PSSession configuration, not tied to a specific PowerShell version.
When Enable-PSRemoting command is run, it creates 2 sessions configurations:
first, the same as it was before with the name containing the current version expressed as: 'PowerShell.$PSVersionTable.GitCommitId'
second with the default name 'PowerShell.6' so that administrators wouldn't have to guess which specific version is installed on the target.
PR addresses the issue: #6470
* Use UTC datetime in Get-Date -UFormat %s
Fix %l output from 0..11 to 1..12
Fix %V using Gregorian calendar
* Use a workaround for ISO 8601 week of year (uformat %V)