Launch COM server for elevated use via packaged path #4567
Conversation
| LONG result = FindPackagesByPackageFamily(pfn.c_str(), PACKAGE_FILTER_HEAD, &count, nullptr, &bufferLength, nullptr, nullptr); | ||
| THROW_WIN32_IF(result, result != ERROR_INSUFFICIENT_BUFFER); | ||
|
|
||
| for (size_t i = 0; i < 10 && result == ERROR_INSUFFICIENT_BUFFER; ++i) |
There was a problem hiding this comment.
Is this for "in case a new package is added between our calls"?
|
@JohnMcPMS Could this also help with general COM stuff ?.we are using the COM API to install/update packages. But performance is worse than using CLI . CLI works most of the time but COM method delivers "No applicable installer" for many packages. And cli with same options works just fine. Code must be also fine because some packages can be updates via COM.api. but success rate is 40% in COM vs 90% in cli If not I am happy to provide some details :) |
This should have no functional impact and probably wouldn't even affect your use. Creating an issue with details is the best thing to do. Make sure you include how exactly you are using the COM API (user, session, where you got the binaries, etc.) |
|
@JohnMcPMS #4589 here is the issue :) |
Change
Leverage the feature that allows launching a packaged process via its packaged executable location as long as there is a matching alias. This better ensures that we are launching the correct process.
Validation
While the dev usage can't use this path due to the way it and development deployed packages work, the code to find the executable is being run to ensure correct functionality. It is then replaced with the alias path that was being used previously.
Microsoft Reviewers: Open in CodeFlow