Why is it that with the following relevance statement the resolve true
(version of file "ms-teams.exe" of folder whose (name of it as lowercase contains "MSTeams" as lowercase) of folder "C:\Program Files\WindowsApps" as string as version < "26163.405.4842.717" as version)
these versions are resolving as true and should be false
26163.405.4842.717
26183.1903.4892.4448
That's odd. On my system this query, as written, evaluates to false, where I have Teams v26183.1903.4892.4448 installed.
Also, I would note that the casting to string and back to version ("as string as version" before the less than operator) is not strictly required, since the output of the inspection version of file "ms-teams.exe" results in a version object.
yeah it is like some machines it resolves correctly others it doesn’t it makes me scratch my head.
Perhaps an analysis might shed some light. I'd start with the folder names.
Sometime once package is upgraded especially in case of MS teams garbage older version is left in folder. This would be worth checking
I have plenty of anlaysis on it. it doesn’t really make any logical sense
teams DIR - folders whose (name of it as lowercase contains "MSTeams" as lowercase) of folder "C:\Program Files\WindowsApps"
Teams Version - version of file "ms-teams.exe" of folder whose (name of it as lowercase contains "MSTeams" as lowercase) of folder "C:\Program Files\WindowsApps"
maximum of (preceding text of first "" of following text of first "" of name of it as version) of folders whose (name of it as lowercase starts with "msteams_") of folder "C:\Program Files\WindowsApps" < "26163.405.4842.717"
Try this. Let me know if it works. I am testing further on another device
FWIW, I often find that extractions that should automatically type a certain way... don't. Did the developer improperly type their registry entries? Are the inspectors being weird? Dunno.
Our template for upgrade relevance has been this for some years:
(value "DisplayVersion" of it as string as version < "REPLACE" as version)
pad of ("STRING" as version) is also sometimes necessary.
TL;DR if you want version comparison operators, you need to be explicit about version typing.
there is only a single directory for MS teams. We have a process that will clean some of those nasty old versions as we have had vul findiings on having the old dir’s hanging around.
I'm not sure this approach will necessarily make a difference, but sharing here just in case:
exists file "ms-teams.exe" whose (version of it < "26163.405.4842.717" as version) of folder whose (name of it as lowercase contains "MSTeams" as lowercase) of x64 folder "C:\Program Files\WindowsApps"
This analysis result you posted is a really good way to test, but it's not clear to me whether all of these that you're listing are reporting the wrong comparison.
For at least one of the systems that is incorrectly reporting True on this, could you run this query in either the Fixlet Debugger, or in the WebUI Query App?
q: (pathname of it, version of it, version of it < "26163.405.4842.717" as version) of file "ms-teams.exe" of folders whose (name of it as lowercase contains "MSTeams" as lowercase) of folder "C:\Program Files\WindowsApps"
That should get you individual responses for each file it finds, the version that it's finding from the file, and what it thinks the comparsion result actually is.
For example on mine it shows
A: C:\Program Files\WindowsApps\MSTeams_26183.1903.4892.4448_x64__8wekyb3d8bbwe\ms-teams.exe, 26183.1903.4892.4448, False
I do wonder whether 32-bit redirection is involved in this problem
Just to throw another option into the pot, Teams appears to be a registered app so one could use the regapp inspector instead of parsing all folders.
Q: (pathname of it, version of it, version of it < "26163.405.4842.717" as version) of regapps "ms-teams.exe"
A: C:\Program Files\WindowsApps\MSTeams_26163.405.4842.717_x64__8wekyb3d8bbwe\ms-teams.exe, 26163.405.4842.717, False
T: 1.480 ms
I: plural ( string, version, boolean )