This change moves powershell to .NET Core 2.0. Major changes are:
1. PowerShell assemblies are now targeting `netcoreapp2.0`. We are using `microsoft.netcore.app-2.0.0-preview1-001913-00`, which is from dotnet-core build 4/4/17. We cannot target `netstandard2.0` because the packages `System.Reflection.Emit` and `System.Reflection.Emit.Lightweight`, which are needed for powershell class, cannot be referenced when targeting `netstandard2.0`.
2. Refactor code to remove most CLR stub types and extension types.
3. Update build scripts to enable CI builds. The `-cache` section is specified to depend on `appveyor.yml`, so the cache will be invalidated if `appveyor.yml` is changed.
4. Ship `netcoreapp` reference assemblies with powershell to fix the issues in `Add-Type` (#2764). By default `Add-Type` will reference all those reference assemblies when compiling C# code. If `-ReferenceAssembly` is specified, then we search reference assemblies first, then the framework runtime assemblies, and lastly the loaded assemblies (possibly a third-party one that was already loaded).
5. `dotnet publish` generates executable on Unix platforms, but doesn't set "x" permission and thus it cannot execute. Currently, the "x" permission is set in the build script, `dotnet/cli` issue [#6286](https://github.com/dotnet/cli/issues/6286) is tracking this.
6. Replace the use of some APIs with the ones that take `SecureString`.
7. osx.10.12 is required to update to `netcoreapp2.0` because `dotnet-cli` 2.0.0-preview only works on osx.10.12.
8. Add dependency to `System.ValueTuple` to work around a ambiguous type identity issue in coreclr. The issue is tracked by `dotnet/corefx` [#17797](https://github.com/dotnet/corefx/issues/17797). When moving to newer version of `netcoreapp2.0`, we need to verify if this dependency is still needed.
Now `New-Item` can create a file symlink to a file target or to a non-existent target. It can also create a directory symlink to a directory target on Windows.
On Unix, it is a convention for shells to accept `-i` for an interactive shell and many
tools expect this behavior (`script` for example, and when setting powershell as the
default shell) and calls the shell with the `-i` switch. This change is breaking in
that `-i` previously could be used as short hand to match `-inputformat` which now will
need to be `-in`.
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