* Update 'Microsoft.PowerShell.CoreCLR.Eventing' to resolve conflicts
* Add reference to 'System.Diagnostics.EventLog' to build Microsoft.PowerShell.Commands.Diagnostics on Unix
* Stop compiling Get/New-WinEvent on Unix
This breaks rendering of images for Windows 7 and Server 2008R2,
but it's required for accessibility purposes so that the High
Contrast Black theme renders text correctly for accessibility.
(Unfortunately, BMP does not support transparency.)
Add support in packaging.psm1 to produce a .msix AppX package. Update the docker image to use the new msix package type. Update the associated yml files so AzDevOps performs the build.
## PR Context
Enable publishing PSCore6 to Microsoft Store
Fixes#8919
Preserve user shortcuts pinned to Taskbar during MSI upgrade by not removing shortcuts in this case (assuming the user has not changed the installation directory), see https://stackoverflow.com/a/33402698/1810304
This also requires the Guid to not always be re-generated, which PR #7701 originally added to ensure shortcuts get removed when RTM and preview are installed, the underlying problem was rather that RTM and preview shared the same GUIDs, therefore the GUIDs are hard-coded again but different for RTM and preview, therefore the shortcuts will still always get removed on uninstall. But this also means those GUIDs should change when the default installation directory changes, i.e. in PowerShell 7. Should we write the code to already take this into account that it does not get forgotten?
Tested by first reproducing the issue by building installers locally (and bumping the patch version. Then the fix was applied to verify the solution, it. For this to take effect the version from which an MSI is being upgraded must have this fix already, i.e. if this fix got shipped in `6.2.1`, then on upgrading to it, the issue would still occur but when upgrading `6.2.1` to `6.2.2` the shortcut would start being preserved. I am wondering if we could maybe improve this to show effect earlier by trying to extract the used (auto-generated) GUIDs in the `6.2.0` and `6.2.0-rc` packages out and use them...
Please not that we probably need to take this out for `7.0` because the base installation directory will change. This also assumes that the user has not specified a different installation directory on upgrade but this is a bit of an edge case where I think other things might break as well.
## PR Summary
Related: #8699
## PR Context
Because `PowerShellGet` does not support publishing/saving module on a per platform basis (see [this](https://github.com/PowerShell/PowerShellGet/issues/273) issue), PowerShell currently also ships the fullclr binaries of `PackageManagement`, which it does not need. Therefore removing it to minimise the package size, this saves 1.19 MB.
Major changes are as follows:
- Avoid `SecuritySupport.IsProductBinary` and unnecessary AMSI/suspicious code scan at startup time
- Update `CompiledScriptBlockData.IsProductCode` to avoid unnecessary calls to `IsProductBinary`, which attempts to retrieve catalog signature of the target file.
- Update `PerformSecurityChecks` to skip AMSI and suspicious code scan for the `.psd1` file that contains a safe `HashtableAst` only.
- Use customized `ReadOnlyBag` instead of `ImmutableHashSet` so that we can avoid loading the `System.Collections.Immutable.dll` completely.
- Replace `SHA1` with `CRC32` when generating module analysis cache file name
- This remove the loading of `System.Security.Cryptography.Algorithms.dll` at startup
- Move `ConvertFrom-SddlString` to C# to remove the `Utility.psm1` file.
- Crossgen `Microsoft.ApplicationInsights.dll` and enable tiered compilation
- Even pwsh with crossgen assemblies spends a lot time in jitting at the startup, about `191.6ms` comparing with `24.7ms` for Windows PowerShell.
- Jitting `Microsoft.ApplicationInsights.dll` takes about `51.6ms`.
- By crossgen `Microsoft.ApplicationInsights.dll` and enable tiered compilation, the jitting time drops to about `98.9ms`.
Since we don't explicitly set the window title, it just shows the path to `pwsh.exe`. Fix is to use the `-Command` parameter to set the window title.
Fix#8163
Guidance is that we can just have the major version at the top "PowerShell 6" and not worry about updating the minor version with each release. The change is on line 230. Word made the other changes to the RTF.
The variable was set to empty (meaning to delete the variable) in the non-preview case and the build fails.
The fix avoids setting the variable to empty
Fixes underlying problem of #3341. Related: #2881
When multiple versions (e.g. RTM and preview) of PowerShell are installed via the MSI and one is being uninstalled, then the start menu shortcut does not get removed due to the shortcut component being not unique per version. This also applies to an upgrade scenario. Therefore use an auto-generated Guid (`*`)
Remove code from build.psm1 that save the modules to a versioned folder. For servicing reasons after release it is preferred and easier to not have the versioned folder so that we can directly replace modules that need to be serviced (MSI specifically makes it difficult to service a module if the folder path changes).
- `ConvertFrom-Markdown` is used for converting a markdown document or string to a MarkdownInfo object. It can optionally return an HTML or a VT100 encoded string in addition to an AST of the markdown document.
- `Show-Markdown` is used to either display the VT100 encoded string on the console or redirect the HTML string to the browser.
- `Set/Get-MarkdownOption` cmdlets are used to view or set markdown rendering options.
* update to latest package references
* update runtime framework
* update sdk
* automatically read NuGet package dependency info from csproj, where version info is fully qualified
* update file.wxs
To support PowerShell modules built with .NET Windows Compatibility Pack, we decided that it was best to ship the WCP assemblies with PS Core. This also adds many new .NET APIs be default while only adding ~3.5 MB additional disk footprint (to a ~137 MB install currently).
Also update the build to adopt the official .NET Core 2.1.
* 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
Fixes#6590 by adding registry keys to support the existing explorer context menu also when being inside a library folder. It follows the existing pattern that was already applied to special cases such as drives, Desktop, etc.
Manually Tested on Win 10 1709
Thanks to @mklement0 for triaging the issue and already researching the required registry key (he should also be included in the release notes)
- 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.
Since a PR added support to opt out of telemetry via an environment variable, we can remove the,
always intended to be a temporary, solution of deleting a file to opt out of telemetry since the
environment variable can be defined at the system level and exist before even installing PowerShell Core.
Because the variable is defined as opt out, a value of true, yes, or 1 means no telemetry is sent.
* In cases where the header spans multiple rows, need to correctly calculate whitespace and trim appropriately
* Use System.Span<int> and C# 7.2 language in SMA
* Added new ref assemblies to Files.wxs
refactor tests to remove similar xml content
added single column test case
- Implementation of PowerShell/PowerShell-RFC#115 (If anything changes in the RFC, we will treat it as a bug, and fix it later)
- Update registry and directory paths to use 6 for the version for stable and 6-preview for a preview release
- Add checkbox to set path
- default checkbox to off for preview builds and on for stable builds
MSI: remove the version from the product name
During patching the original MSI information is displayed.
This makes installing a patch for an MSI with a specific version very confusing.
MSI: Make sure that file components are patchable
- avoid changing names and guids of components between builds as this prevents patch generation
- This required submitting the file generated by heat
- add code to make sure the generated file is not out of date
- add `wixpdb` output when creating `MSI` package
- capture `wixpdb` in official build
- clean up anything left behind from previous MSI builds before starting MSI build to prevent using dirty files.
- make sure MSI creation fails if there is an error
- ignore `.wixpdb` files in git
- Add functionality to `Start-NativeExecution` to
- only display output if there is an error
- log caller information
- WXS validation error fixes
- Remove unused `ExitDialog` to fix ICE82
- Add KeyPath to `SetPath` to fix ICE18
- Use `HKMU` which translates to `HKLM` to runtime to fix various validation errors about creating the shortcut
- Suppress Validation errors
- suppress ICE61, which is about same version upgrades being allowed
- suppress ICE57, caused by the shortcut not being installed per user
Add registry value for easy detection. For example, the presence of a single key of 6.0.* x64. This is much faster than MSI detection.
Note there are currently two GUIDs, one for 6.0.* x64 and one for 6.0.* x86.
fixes#6090
Current README uses a PNG which doesn't scale for high dpi displays (starts to look fuzzy).
Created 64 pixel wide version of svg of the black logo and inserted into README.md.
Note that it currently doesn't render as the absolute URL points to master so that it gets
rendered correctly in other places where the README.md is used (like docker hub).
Changes the Windows start menu folder name from ProductSemanticVersionWithName to ProductSemanticVersionWithNameAndOptionalArchitecture - now the start menu is `PowerShell` for all versions.
This is the continuation of PR 5499 that had to be abandoned due to a fatal merge conflict and I did not want to risk accidentally reverting recent fixes.
Remove unnecessary/unused default for productGuid because it always gets a new Guid when being called from Start-PSPackage
Add defaults for required files but also add extra path validation attribute
Rename ProductGuid to ProductCode
Make explorer context menu registry entries platform specific to allow them to work also when both x86 and x64 are installed. The main menu has a " (x86)" appended to the main menu as well.
Fix bug #5597: x86/x64 installer are uninstalling each other when installing either of them:
-Make x86 installer to be installed as an x86 component (-arch argument to candle.exe, which sets the `sys.BUILDARCH` variable)
-Make the UpgradeCode unique per platform
-Replace `var.ProductTargetArchitecture` variable with sys.BUILDARCH use to have only 1 variable for the architecture
-Additionally, the architecture was appended to the package name to be able to distinguish the installations.
Move definition of Launch PowerShell checkbox to the top to allow toggling it using the spacebar (the Enter key already defaults to the Finish button).
Reuse product name variable.
A new dialogue is added in the Windows installer to offer the option of adding explorer.exe context menus to open PowerShell in the current location as a normal shell or as administrator. The context menu entries are achiveven via registry entries and is available when right-clicking on:
- the background of explorer
- a folder in explorer
- a drive in explorer
- on the Desktop
