* enable win-arm and win-arm64 builds
* fix using arm64 tools for build
fix finding vs2017 dynamically
* change install-powershellremoting.ps1 script to use reg provider rather than reg.exe so that error doesn't show on success
fix formatting issue in cmake.defs
* add check that path being read from config file is valid
address PR feedback
* fix copying of PowerShell.Core.Instrumentation as VS2017 puts it in $HOME/source
address PR feedback
* remove pester module
* restore Pester as a module only in CI build from the git repo
* mark appveyor builds as CI builds
* remove pester exclusions
* mark travis builds as ci
* exclude publish folder from spell check
* do not run spell check on publish folder
- Fix build in vscode
- Add v2.0.0 tasks.json thanks to Keith Hill
- Add '/property:GenerateFullPaths=true' to build to fix the $mscompile 'problem matcher' not working issue.
Replace the static `powershell.inc` filename with a name based on the current RID, so that the build doesn't confuse when running in the same local repository on WSL.
* Add two files that need to be signed
* make sure to set PSModuleRestore to true when expanding a signed build because we run PSModuleRestore at that point.
* suppress output of CmdLets which are noisy
- Include a serialized version of PSOptions in an includesymbols zip
- Add a function which will create a zip package from the expanded includesymbols zip and a folder of signed files
- Add a function to restore an includesymbols zip as a build and populated PSOptions with the options
- Add install-powershell.ps1 to install powershell core packages on windows.
- Update Start-PSBootStrap to check and install the latest PSCore package on Windows.
Fix#5260 - with this fix folks shouldn't hit the version mismatch check.
The approach is to see if the dotnet in the current PATH has a compatible SDK. Folks will have a globall installed dotnet if they've installed VS, VSCode C# ext or have installed the .NET Core SDK. This verion may not have the SDK required by PSCore. And the global cannot see user local dotnet SDK installs. So if the global dotnet doesn't have the right SDK, we prepend the path to the user's local dotnet dir.
Also, updateed $dotnetCLIRequiredVersion to read its value from global.json so there is one less source of the truth (for the SDK version).
- Build PowerShell.Core.Instrumentation.dll - Resource-only binary for the ETW resources.
- Create a registration script for registering/unregistering the ETW provider.
pwsh.exe today doesn't contain file version information and the icon is only associated with the shortcut file and not the exe
Fix is to use rcedit to embed:
icon
product version
file version
product name
copyright
Fix#2883Fix#5166Fix#5034
- Rename powershell.exe to pwsh.exe
- Fixe appveyor.psm1
- Update MSI to include 'pwsh' in path and app paths
- Revert change for hyper-v powershell direct
- Update names in packaging.psm1.
- Fix check for SxS
Currently, if a user does not clone with the `--recursive` flag or run `git submodule update --init`, `Start-PSPester` will fail to run due to the missing Pester module. While the error hints at the Pester module not being found, there is no suggested way of fixing the issue presented to the user.
This change makes a helpful warning to appear at the beginning of the execution of `Start-PSPester` if the Pester module cannot be found.
When uploading CodeCoverage artifacts, `Compress-TestContent` is called which calls `Publish-PSTestTools` to build test tools. The build output was captured by `$codeCoverageArtifacts` which causes `Push-AppveyorArtifact` to spit out a lot of errors. The issue is fixed by this change.
The code in `AssemblyLoadContext.dll` doesn't need to be in a separate DLL anymore.
S.M.A.dll depends on `AssemblyLoadContext.dll`, so keeping that code out of S.M.A.dll doesn't help make S.M.A smaller size or less dependent. So the code in `AssemblyLoadContext.dll` is moved to `S.M.A.dll` and then we remove `AssemblyLoadContext.dll`.
The changes are:
- Move `CorePsAssemblyLoadContext.cs` to `src\S.M.A\CoreCLR\`
- Update `CorePsAssemblyLoadContext.cs` to get the test took moved to `Utils.InternalTestHooks` and update tests
- Update `build.psm1` and `.csproj` accrodingly
- Update `pwrshcommon.cpp` to remove `AssemblyLoadContext.dll` from the TPA list.
- `S.M.A.AssemblyExtensions` is removed as `PackageManagement` has finished their move to .NET Core 2.0. (I will work with Bryan to get the latest version uploaded to powershell-core)
* Make the build output the WiX compilation log if it failed.
Before it was not outputting it not at all because the build output is an array that was piped directly to 'Write-Verbose' instead of converting it to a string using 'Out-String'
Because the WiX log is usually quite verbose (around 250 lines), the log is only shown if there must have been a compilation error due to the missing MSI
* PR 4831: Use -Verbose option on Write-Verbose to force output in build as suggested in review.
* Add a switch to force tests to fail for testing CI system to Start-PSPester
* [includeFailingTest] Add commit tag to force tests to fail for testing CI system
Extract information about the release tag, number of commits since the tag and the hash of the latest commit within a MSBuild target, and bake that information into version properties of the assemblies appropriately.
Introduce new test module 'WebListener.psm1'.
Now web HTTPS tests can use it to exclude using external sites.
PowerShell/PowerShell#4609
* [Feature] Add Tests for Web Cmdlet Certificate Authentication
PowerShell/PowerShell#4609
* [feature] Add new app to Publish-PSTestTools refactor tests
also add ASP.NET to .spelling
* [feature] spelling fix
* [feature] revert badssl changes
* [feature] Impliment suggestions
* [feature] Spelling, var rename, port 8443 to 8083
rebase fix conflict
* [feature] Rename to HttpsListener and Module-ize
.
* [feature] password protect ClientCert to fix macOS import issue
* [feature] Rename to WebListener
* Rename HttpsListener to WebListener
* Switch Listener from Razor pages to MVC
* Address PR feedback
* Adjust tests
* [feature] Address PR feedback
* [feature] Replace missing smeicolons
* [feature] Address PR Feedback
* [feature] Cleanup and minor fix
* Enum was not used
* GetStatus() was not accessing the correct property chain
* Added -Test param to make URL generation smoother in test code and to fix double / issues
* [feature] More minor fixes
* Https when it matters.
* Expand property... not exclude..
* Remove superfluous and outdated ToString() override
* [Feature] Move ClientCeret.pfx to WebListener Module
* Move the cert
* Adjust Get-WebListenerClientCertificate
* Remove cert from csproj
* ActionResult -> JsonResult (was mistakenly left as ActionResult during testing)..
* [Feature] Move ServerCert.pfx to Module
* Move cert
* Upate csproj
* Update module
* Add/Update README.md's
CI Retest.
* Add ability to verify a test run using the `-passthru` object from pester
* update travis-ci to use `-passthru` object to verify test results
* Address PR feedback
* call show-pspestererror with a named parameter
Fixes#1193 for most scenarios. The remaining scenario to be addressed is the Nano Server bring-up scenario. To continue supporting that scenario, I left the Install-PowerShellRemoting script in place.
This change
1. Ports Enable-PSRemoting and Disable-PSRemoting to PowerShell Core
2. Adds side-by-side PowerShell Core remoting support to the PSSessionConfiguration cmdlets and PSRemoting cmdlets.
3. Ports PSSessionConfiguration tests
This change also introduces a behavioral difference. The PSRemoting and PSSessionConfiguration cmdlets are now context-sensitive and only work for endpoints that match the PowerShell type. For example, Get-PSSessionConfiguration, when running in PowerShell Core, will only return PowerShell Core WinRM endpoints. It will only modify PowerShell Core WinRM endpoints and cannot be used to configure Windows PowerShell endpoints.
There are following major changes:
- `Start-PSBootstrap -BuildWindowsNative` installs the native dependencies required for building PSRP binary. Without `-BuildWindowsNative`, it only installs the dotnet-SDK on Windows platform.
- `Start-PSBuild` doesn't build Windows PSRP binary. Instead, `Start-BuildNativeWindowsBinaries` is added to build it. After the build, 3 files (`'pwrshplugin.dll'`, `'pwrshplugin.pdb'`, `'Install-PowerShellRemoting.ps1'`) will be bin-placed at `src\powershell-win-core` like before.
- The NuGet package `'psrp.windows'` is added to `powershell-core` feed, and we reference it in `powershell-win-core.csproj` to get the Windows PSRP related files. Files (.dll and .pdb) in the package are from the beta.4 release build.
- Fix PSScriptAnalyzer warnings of type PSAvoidUsingCmdletAliases for 'ForEach-Object' (alias is '%' or 'foreach')
- Fix PSScriptAnalyzer warnings of type PSAvoidUsingCmdletAliases for 'Where-Object' (alias is '?' or 'where')
- Fix PSScriptAnalyzer warnings of type PSAvoidUsingCmdletAliases for 'Select-Object' (alias is 'select')
- Fix PSScriptAnalyzer warnings of type PSPossibleIncorrectComparisonWithNull. Essentially, $null has to be on the left-hand side when using it for comparison.
- A Test in ParameterBinding.Tests.ps1 needed adapting as this test used to rely on the wrong null comparison
- Replace a subset of tests of kind '($object -eq $null) | Should Be $true' with '$object | Should Be $null'
Added a checkbox (unchecked by default) to the last dialogue of the Windows installer to provide the option of opening PowerShell because that's what most people want to do if they installed PowerShell.
This change is only for Windows and appends the Windows PowerShell PSModulePath on startup via a default profile. Depending on the data/feedback we get, we can decide what to do (opt-in vs opt-out) as we get closer to a release candidate.
* ClrVersion property of $PSVersionTable is not useful with CoreCLR and end users should not be using it
that value to determine compatibility. Recommendation from dotnet team is to remove that property.
* Removed internal members used for CLRVersion
* removed CLRVersion from FullCLR build as well
* added additional information to run `start-psbootstrap -buildnative` if cmake is not found
Fixed tests that were failing or throwing unnecessary information on-screen.
Updated the paths to powershell.exe as per the new artifact layout.
Added Publish-PSTestTools to Compress-TestContent
Added PS Test tools to PSModulePath before starting tests.
Wix toolset is part of the AppVeyor base image. The daily build did not generate a MSI since Wix toolset was not found.
AppVeyor updated the Wix version in the base image and our checks failed.
The fix removes the hardcoded version from path. It also guards against multiple side-by-side versions.
* First iteration
* Second iteration
* Third iteration
* Fourth iteration
* Fifth iteration
* Revert the temporary workaround
* beta.1 release only support Mac OSX 10.12+
Use 2.0 CLI/SDK of version `2.0.0-preview1-005952` to keep in sync with the .NET Core 2.0 //Build dogfood instructions. The version of `Microsoft.NetCore.App` in use is `2.0.0-preview1-002106-00`.
This is limited to the console host and is not meant as generalized telemetry code for PowerShell Core. It will capture the GitCommitID and Platform Information when the console host starts. It enables opting out of sending telemetry.
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.
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.
* 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
