[Packaging] Support x86 and x64 MSI builds #26640
Conversation
️✔️AzureCLI-FullTest
|
️✔️AzureCLI-BreakingChangeTest
|
|
Thank you for your contribution! We will review the pull request and get back to you soon. |
jiasli
changed the title
Separate agents will build separate packages and publish them as needed to avoid regressions to existing pipeline.
|
The upgrade behavior is as below:
|
|
We have finalized related names to be
The product name has been changed from The product name change should not be considered a breaking change, because the official document https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-windows doesn't declare the product name, so the product name is not guaranteed to remain the same across versions. If you have script relying on the product name |
|
Documentation not yet updated with 32-bit and 64-bit information? |
|
@aluty The PR is not merged yet, we are working on it. MicrosoftDocs/azure-docs-cli#3759 |
|
This new azure-cli-2.51.0.msi triggers #26464.
The weird thing is Python version is not upgraded between Azure CLI 2.50.0 and 2.51.0. I checked Both are created on Tuesday, February 7, 2023, 5:30:06 PM:
They have the same SHA256 I am not sure about the exact root cause. Possible root causes are
|
msiexec /i <path to MSI> /l*vx %TEMP%\install.logAttach or send to me and I can take a look. I did test the various upgrade paths (new install, old -> new for x86, old x86 -> new x64, and new x86 -> new x64) and they all worked for me. |
|
Thanks @heaths for the comment.
May I know which "Resource Manager" you are referring to? Is it a file? How It currently only supports 32-bit Azure CLI and 32-bit MSI. This issue doesn't happen if you directly install MSI and not through Previously before this PR, we have observed:
We did not upgrade Python from Azure CLI 2.50 to 2.51 and the The weird thing I mentioned in #26640 (comment) contradicts the previous behavior and we are not sure why. |
|
Restart Manager is a Windows feature that's been in since Vista, IIRC. You can search for it. Because python.exe is waiting for msiexec.exe to finish, this will happen. It isn't new based on this PR. You can pass |
Our previously observation is that if Python version is not upgraded during the installation, this Files in Use window will not be shown. That's why we are curious about it.
This is exactly what #26464 is doing. #14803 added the We refined it in #19192 to download the MSI to a temporary folder under Once
If
|
And that confirms what I said in my comment above. If the file (component) doesn't need to be upgraded, Restart Manager isn't used for that file because it won't be touched. Once it's upgraded, though, this functionality is working exactly as designed. So you can either make sure (as much as you can) python.exe isn't running (don't wait), or try passing |
We will do this in #26464.
There is no fancy logic currently to create the
In order to know whether |
Nothing is stopping you from copying the python.exe process to another file and executing that in the same directory, so that all library and package references are resolved correctly. python.exe would be replaced while _python.exe (e.g.) continues to run and you can still wait for it. This is a common workaround for cases like this. |
As far as I know, this is not possible on Windows, because Windows doesn't support replacing a process like This is of course not what we want - we want the control to be given back to the terminal after Python exposes Another workaround is to modify the |
|
Apps using the console subsystem do not return control immediately - only windows subsystem apps. python.exe is compiled to use the console subsystem. Even if it used the windows subsystem, you can use The main point is that: if you're going to hold |
What I was thinking is the pure Python solution. Using It doesn't return immediately if the caller
This is doable with a pure cmd script solution, but I think that'll overly complicate the |
|
Azure DevOps runner image (Windows) has switched to 64-bit MSI (actions/runner-images#8096). Runners will be updated gradually after 2023-8-25. |
Close #18766