Bumps System.Security.AccessControl from 4.6.0-preview6.19303.8 to 4.6.0-preview.19113.10.
Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
Bumps System.Security.Principal.Windows from 4.6.0-preview6.19303.8 to 4.6.0-preview.19113.10.
Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
Bumps System.Security.AccessControl from 4.6.0-preview6.19303.8 to 4.6.0-preview.19113.10.
Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
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.
Removes appveyor stuff
## PR Context
<!-- Provide a little reasoning as to why this Pull Request helps and why you have opened it. -->
#8686 , appveyor removed
* Add shim dll to redirect to appropriate runtime
* Build updates for creating global tool package
* Add building global tool to nuget.yml
* Add azure upload of nuget packages
Refactor Unified Release Build
- Make injecting the nuget.config a template
- Make setting the version variable a template
- Add parameters to templates where needed
- Run defender scan before uploading linux packages (and rename step to plain english)
Update the universal build to also build the framework package needed for the dotnet sdk container image.
## PR Context
We build the package in individual builds. This change brings over the steps in the universal build.
Update `New-ReferenceAssembly` and `New-UnifiedNugetPackage` to generate reference assembly for `Microsoft.PowerShell.Commands.Utility.dll` and properly deploy it for `Microsoft.PowerShell.Commands.Utility` NuGet package and `Microsoft.PowerShell.SDK` NuGet package.
An incremental step to fix, eventually, #8121
Update `New-ReferenceAssembly` and `New-UnifiedNugetPackage` to generate reference assembly for `Microsoft.PowerShell.Commands.Utility.dll` and properly deploy it for `Microsoft.PowerShell.Commands.Utility` NuGet package and `Microsoft.PowerShell.SDK` NuGet package.
An incremental step to fix, eventually, #8121
When installing (or upgrading) Preview builds the component ids for the files are the same as the installed files from the stable MSI. MSI sees this and assumes the file is already installed so skips installing files that haven't changed (been updated) which results in missing files in the preview install folder and pwsh fails to start. Fix is to dynamically generate new component ids (and compoentrefs) in `files.wxs` using `_Preview` suffix and use that when building a preview package.
Tested manually.
cc @bergmeister if you can help validate different scenarios.
Fix https://github.com/PowerShell/PowerShell/issues/8289
Remove tilde from Linux preview packages.
- Since we have a separate package for preview, we don't need a second indicator that these packages are preview.
- Also, many system we use to release don't like the `~` character, which leads to manual interventions and errors.
