New vswhere: now with more properties!

Heath Stewart

The latest release of vswhere now outputs additional properties as requested, along with catalog properties and a way to disambiguate nested properties – not that there are any currently. You can specify the nested properties followed by a property name like “properties/nickname”. Delimiters supported are “_”, “/”, and “.” to fit with the text, JSON, and XML formats. You can use any delimiter with any format, however.

The default output for an instance now looks like:

[
  {
    "instanceId": "890353f3",
    "installDate": "2017-09-16T01:24:28Z",
    "installationName": "VisualStudio/15.4.0+27004.2002",
    "installationPath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Enterprise",
    "installationVersion": "15.4.27004.2002",
    "productId": "Microsoft.VisualStudio.Product.Enterprise",
    "productPath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Enterprise\\Common7\\IDE\\devenv.exe",
    "isPrerelease": false,
    "displayName": "Visual Studio Enterprise 2017",
    "description": "Microsoft DevOps solution for productivity and coordination across teams of any size",
    "channelId": "VisualStudio.15.Release",
    "channelPath": "C:\\Users\\heaths\\AppData\\Local\\Microsoft\\VisualStudio\\Packages\\_Channels\\4CB340F5\\catalog.json",
    "channelUri": "https://aka.ms/vs/15/release/channel",
    "enginePath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\Installer\\resources\\app\\ServiceHub\\Services\\Microsoft.VisualStudio.Setup.Service",
    "releaseNotes": "https://go.microsoft.com/fwlink/?LinkId=660692#15.4.0",
    "thirdPartyNotices": "https://go.microsoft.com/fwlink/?LinkId=660708",
    "catalog": {
      "buildBranch": "d15svc",
      "buildVersion": "15.4.27004.2002",
      "id": "VisualStudio/15.4.0+27004.2002",
      "localBuild": "build-lab",
      "manifestName": "VisualStudio",
      "manifestType": "installer",
      "productDisplayVersion": "15.4.0",
      "productLine": "Dev15",
      "productLineVersion": "2017",
      "productMilestone": "RTW",
      "productMilestoneIsPreRelease": "False",
      "productName": "Visual Studio",
      "productPatchVersion": "0",
      "productPreReleaseMilestoneSuffix": "6.0",
      "productRelease": "RTW",
      "productSemanticVersion": "15.4.0+27004.2002"
    },
    "properties": {
      "campaignId": "844478574.1505524861",
      "channelManifestId": "VisualStudio.15.Release/15.4.0+27004.2002",
      "nickname": "",
      "setupEngineFilePath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\Installer\\vs_installershell.exe"
    }
  }
]

Most of the properties are provided through the ISetupPropertyStore. This interface is implemented by ISetupInstance objects, and provided by ISetupInstance2::GetProperties for custom properties. Starting with Visual Studio 2017 Update 3, you can also get catalog properties by calling IUnknown::QueryInterface on an ISetupInstance object for ISetupInstanceCatalog, which also provides an ISetupPropertyStore from ISetupInstanceCatalog::GetProperties. As we add new features that require persisting properties, they will automatically be exposed.

1 comment

Discussion is closed. Login to edit/delete existing comments.

  • pete dashwood 0

    I believe vswhere is a good tool and long overdue. But there are some pretty basic things it misses. If I have a client with multiple side-by-side versions installed,there are 2 main things I need to know:
    1. installationVersion   -which version is it
    2. productPath            -the full path to the executable (so I can start it up from my application).
    Sadly, although it returns comprehensive data for Community versions (like 2017), legacy instances only return:
    <instance><instanceId>VisualStudio.12.0</instanceId><installationPath>C:\Program Files (x86)\Microsoft Visual Studio 12.0\</installationPath><installationVersion>12.0</installationVersion></instance>
    NOTE: it is the INSTALLATION PATH NOT the PRODUCT PATH.  
    Historically, I have done all kinds of Pilates on the Registry to try and determine where the executables are but the structure of the paths seems to have changed acoss versions and the modern versions don’t conform. I was therefore glad to see vswhere when it arrived. This whole inconsistent mess needed to be sorted and it is good to see someone making an attempt at it.
    If it is at all possible for you to include productPath into legacy instances this would double or treble the value of the tool for some of us…
    Cheers,

    Pete.

Feedback usabilla icon