Select-VSSetupInstance -Latest - is it about install date or version? #40
Comments
|
"the most recent" means most recently installed, which will have a newer InstallDate. I should be checking for the highest version, and if more than one instance has the same version I should pick the one with the latest InstallDate. But now that you call attention to it, I see it's not sorting based on version like I did in vswhere. I'll get that fixed and make sure I have a test covering it. |
Fixes #40 and updates the test data to make sure we're properly sorting and selecting. Also made a corresponding test-only change to Microsoft/vswhere to make sure this case isn't regressed there (was already handled correctly).
Fixes #40 and updates the test data to make sure we're properly sorting and selecting. Also made a corresponding test-only change to Microsoft/vswhere to make sure this case isn't regressed there (was already handled correctly).
The InstanceComparer that was added as part of microsoft#41 to fix microsoft#40 isn't actually able to solve the problem due to the implementation of the ProcessRecord method in SelectInstanceCommand. InstanceComparer is used to sort instances by version and then date, but when iterating over all instances, the latestInstance variable is only set when the latestInstance date is less than the date of the current instance in the loop. This completely ignores the previous OrderBy that was done using InstanceComparer. The simplest solution at this point is to always set the latestInstance variable when the Latest flag is set because the collection is already sorted in the desired order and no additional comparisons are necessary.
|
@heaths, I have been experiencing an issue where the -Latest flag is picking my VS 2017 instance that was installed after my VS 2019 instance and I believe this discussion is relevant. @Hadronicus appears to have a solution in pull request #53 to this. I noticed that his pull request has been pending approval for over 5 weeks. Are you waiting on something to approve the pull request? Is there additional work that needs to be done for you to approve it that I'm just not seeing communication for? I'm happy to contribute to the effort if needed. Thanks. |
The InstanceComparer that was added as part of #41 to fix #40 isn't actually able to solve the problem due to the implementation of the ProcessRecord method in SelectInstanceCommand. InstanceComparer is used to sort instances by version and then date, but when iterating over all instances, the latestInstance variable is only set when the latestInstance date is less than the date of the current instance in the loop. This completely ignores the previous OrderBy that was done using InstanceComparer. The simplest solution at this point is to always set the latestInstance variable when the Latest flag is set because the collection is already sorted in the desired order and no additional comparisons are necessary.
|
To be honest, I missed this somehow. I've merged this and will get the changes published. Thank you for your contribution! |
|
Thank you @heaths and @Hadronicus. |
|
Unfortunately, we're having a publishing issue at the moment I'm trying to sort out. For now, can you expand the ZIP release and make sure all your existing scenarios work? We have code coverage and detected no regressions, but I'd like to get hands on a prerelease before we push a release (once I get all that working again). |
|
I'll be able to test this tomorrow. Thanks for the info. |
|
I've been running into issues getting Visual Studio's installer to update to the newly released version that are currently blocking me from testing this. I'll provide an update as soon as I have one to give. |
|
The installation of our installer is pretty much just deleting a directory (we make a backup), unzip, and run a finalization process. We've not heard reports of this failing. Could you open a feedback ticket from within the Installer (if you still have one installed) or from within Visual Studio if already installed? That will collected relevant data (at least from within the Installer) we'd need to diagnose the issue. But as long as the query API is installed (which actually installs with the products we install so we retain error handling, download robustness, telemetry, etc.) this module will work. I haven't made any significant changes to the query API in many months. Both these cmdlets and vswhere are designed to work with even the original versions of the query API and rarely make use of new features, which we try to use best-effort if necessary. |
|
Here is my feedback ticket: https://developercommunity.visualstudio.com/idea/668905/vs-installer-fails-to-update-from-v213129607-to-v2.html. Thanks. |
|
Update: I installed the prerelease module in my environment. Get-VsSetupInstance gets the following: DisplayName: Visual Studio Enterprise 2019 DisplayName: Visual Studio Enterprise 2017 Get-VsSetupInstance | Select-VsSetupInstance -Latest is returning the 2017 instance instead of the 2019 instance as I would expect it should. I'll take a look into the change @Hadronicus made as I would expect that his change would have returned the 2019 instance when the latest flag is used. I'll plan to look at this when I come in tomorrow. Thanks for the pre-release to try out. |
|
I was able to repro the problem and will be sure to add an integration test. The problem occurs when piping instances to |
|
@heaths, any idea what the timeline looks like on getting this change into a released version of the tool? Thanks. |
|
Unfortunately, powershellgallery.com is still giving us issues in production. I've pinged the owner again for a status update. |
|
Reopening until published to keep on my radar. |
|
Okay, finally got the powershellgallery.com issue resolved and https://www.powershellgallery.com/packages/VSSetup/2.2.15-g62f3905dea was published. Can you give that a try and make sure everything is working as expected? Then I can publish a release version. |
|
I'll look into this tomorrow when I get into work. Thanks for the support @heaths |
|
Just tested this and it appears to behave as I would expect in my environment now! Thanks for your assistance @heaths. I apologize for the delayed response, I just got to this. |
|
2.2.16 with this fix has been released. |
Select-VSSetupInstance -Latest- is it about install date or version?The help says
so it is not clear whether it is about date or version.
If we take a look at the code
then it looks like it is about installation dates and versions are not checked.
If it is true, is it by design that
Latestdeals with installation dates, not versions?In any case, the help might be more clear about what is checked.
NB (Just for cross-reference) Loosely related to this issue nightroman/Invoke-Build#122
The text was updated successfully, but these errors were encountered: