Do not ship fullclr binaries of PackageManagement - #8700
Conversation
|
I guess that we break in-place upgrade (we will not remove the trash on file system) if removing the components. |
|
Hmm, definitely need Travis Plunk (@TravisEz13)'s approval on this. |
|
Ilya (@iSazonov) Why would the MSI upgrade not remove the old component? And even if it did not remove it, then there would still not be a problem since this folder is not needed/useful for PowerShell Core at all. In the related issue #8699, I also describe that the next version of |
|
We already had a problem with the shortcut key in the registry so we should be careful here. Steve Lee (@SteveL-MSFT) Travis Plunk (@TravisEz13) what do you think? |
|
Seems fine to me. Even if the existing assemblies don't get removed, it didn't make it worse. |
|
We should not consider a patch upgrade scenario during a preview. This change should not be back ported to |
## PR Summary Related: PowerShell#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.
PR Summary
Related: #8699
PR Context
Because
PowerShellGetdoes not support publishing/saving module on a per platform basis (see this issue), PowerShell currently also ships the fullclr binaries ofPackageManagement, which it does not need. Therefore removing it to minimise the package size, this saves 1.19 MB.PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright headerWIP:or[ WIP ]to the beginning of the title (theWIPbot will keep its status check atPendingwhile the prefix is present) and remove the prefix when the PR is ready.[feature]to your commit messages if the change is significant or affects feature tests