Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Core / Dev Environments] Dev Home see the same COM class Ids in separate packages as separate extensions resulting in duplicate requests to the extensions #2451

Closed
bbonaby opened this issue Mar 21, 2024 · 1 comment · Fixed by #3483, microsoft/devhomegithubextension#418 or microsoft/DevHomeAzureExtension#243
Assignees
Labels
Area-Core Related to Dev Home as a whole 🏠 Issue-Bug Something isn't working or needs investigation Priority-1 Resolution-Fix-Available Available in a release

Comments

@bbonaby
Copy link
Contributor

bbonaby commented Mar 21, 2024

Dev Home version

No response

Windows build number

No response

Other software

No response

Steps to reproduce the bug

  1. Install any two versions of Dev Home (Dev, Canary or Preview).
  2. Launch Dev Home and attempt to query for available extensions e.g repo with environments
  3. Enable and create a Hyper-V VM in Windows Hyper-V manager.
  4. Then open Dev Home and navigate to the environments page.
  5. Observe the same VM is duplicated on the page

If you already have Hyper-V VMs created you should see this repo by just doing step 1 and step 4

Note: I mention environments but this is a Dev Home CORE issue itself, as Dev Home uses COM class Ids to identify Dev Home extensions. If the same class Id is in the package.appxmanifest file of multiple packages, Dev Home sees these two packages as separate extensions, but COM will only spin up one out of proc COM server. I'm not sure which server is selected at that point, but since Dev Home sees it as two separate extensions, any request to providers those extensions support is done once for each package. To COM, this means the extensions COM server receives one request for each package that has its class Id as a Dev Home extension. So, in the case of Environments, The Hyper-V extension's class Id is the same across Dev Home build rings and because of the above, it receives two requests for compute systems (VMs) from Dev Home when multiple Dev Home packages are installed.

This also means that if you have multiple Azure extension packages (Dev, Canary, preview) installed, you'd receive duplicated Dev Boxes for example.

Expected result

Only one package is mapped to an extension class Id. Dev Home handles allowing the user to select the extension they want to use if necessary (I don't know if that part would be a feature request). But overall, only one request per extension should be made for a single COM class Id.

In the environment's scenario, the user should receive only a single response when we query for computes systems from an extension.

Actual result

If you follow the repo steps You'll noticed you'll see the VM duplicated twice when you navigate to the environments page and it loads.

Included System Information

No response

Included Extensions Information

No response

@bbonaby bbonaby added Issue-Bug Something isn't working or needs investigation Area-Core Related to Dev Home as a whole 🏠 Area-Environments labels Mar 21, 2024
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Triage New issue that the core contributors need to triage label Mar 21, 2024
@bbonaby bbonaby removed the Needs-Triage New issue that the core contributors need to triage label Mar 27, 2024
@krschau krschau added this to the Dev Home v0.14 milestone Apr 1, 2024
@krschau krschau modified the milestones: Dev Home v0.14, Dev Home 0.15 May 15, 2024
@krschau krschau modified the milestones: Dev Home 0.15, Dev Home 0.16 Jun 3, 2024
@krschau
Copy link
Collaborator

krschau commented Jun 17, 2024

We think this is also causing trouble with trying to launch Dev Home from an extension using protocol activation.

@krschau krschau removed the Resolution-Fix-Committed Fix is checked in, but may take 3-4 weeks before it's in a release label Aug 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment