Support for UWP callers and a non command line interface API #888
Comments
|
I added a draft proposal here #889 . I do not believe I have permission to link the draft pull request to this item. |
|
Sorry for the general question, but I am not super familiar with COM and many others will possibly wonder the same thing: Will this automatically/inherently enable remote activation of the interface via DCOM as well or does a COM API have to explicitly / separately support DCOM? |
|
@doctordns this is some of the required work to build PowerShell cmdlets. |
|
@jantari The proposed feature wouldn't have DCOM support automatically in the sense that people asking that question would mean. DCOM at some point did refer to any out of process scenario such that COM over RPC could have been called DCOM. But since it was introduced the cross process stuff is now so built in that most everyone would just consider that COM which leaves the cross machine scenarios as what everyone would mean when asking about DCOM. Those scenarios are more complex than regular COM and now pretty unusual. For cross-machine scenarios I would speculate you'd be more likely to get support by a CSP feature request for something like https://docs.microsoft.com/en-us/windows/client-management/mdm/enterprisemodernappmanagement-csp but I have no insight into whether anything like that is planned. If you follow through to the draft proposal you can see that the proposal is an out of proc com server that can return winrt objects to workaround Windows limitations for packaged com (no out of proc winrt servers), so not intended to support remote scenarios. |
|
Thank you, and yes cross-machine DCOM is what I was referring to but I just wanted the clarification - I am not advocating for remote DCOM support in winget, as you've said it has faded into obscurity a bit and many of the usecases I knew of have been replaced by WinRM/WSMAN/remote WMI years ago - which would also work for wingets local COM interface, e.g. interacting with it over a WinRM connection in PowerShell with |
…microsoft#888 (#9) * Prototype of exposing winget to out of proc UWP apps. Create com exe for wrapping a winrt interface with proof of concept call to winget. * Com server changes Support all architectures, progress callbacks. * Update com api proposal * Update samples. * Update API to match review and fix build issues * Update for draft api. API definitions and partial hookup. * Implement more of the api surface Most of the sample code now implemented. * Update with more api implementations. * Fix project settings. * More api implementations and fake vector class. * Switch to new lifetime management for oop * Lifetime management fixes. * Add log parameter. * Remove manual winmd post build generation. * API updates * Merge changes from main branch. * API updates * API updates and implementation
…#888 (#984) * Prototype of exposing winget to out of proc UWP apps. Create com exe for wrapping a winrt interface with proof of concept call to winget. * Com server changes Support all architectures, progress callbacks. * Update com api proposal * Update samples. * Update API to match review and fix build issues * Update for draft api. API definitions and partial hookup. * Implement more of the api surface Most of the sample code now implemented. * Update with more api implementations. * Fix project settings. * More api implementations and fake vector class. * Switch to new lifetime management for oop * Lifetime management fixes. * Add log parameter. * Remove manual winmd post build generation. * API updates * Merge changes from main branch. * API updates * API updates and implementation * Add support for callers using programmatic, non command line interface #888 (#9) * Prototype of exposing winget to out of proc UWP apps. Create com exe for wrapping a winrt interface with proof of concept call to winget. * Com server changes Support all architectures, progress callbacks. * Update com api proposal * Update samples. * Update API to match review and fix build issues * Update for draft api. API definitions and partial hookup. * Implement more of the api surface Most of the sample code now implemented. * Update with more api implementations. * Fix project settings. * More api implementations and fake vector class. * Switch to new lifetime management for oop * Lifetime management fixes. * Add log parameter. * Remove manual winmd post build generation. * API updates * Merge changes from main branch. * API updates * API updates and implementation * Switch from Id to Name due to rest sources * Copyright and project updates. * Update project name. * Add composite changes. * Revert refactor due to locking issue. * Move folder again, pr comment updates * FIx comment. * Remove GetSourceByIdentifier * Match target versions on new projects to existing * Fix percentage calculation. * Add experimental feature. * Fix signed\unsigned warning and progress values. * Fix comments & CompositeSearch::AvailablePackages * fix comment. * Update cppwinrt again * Remove unintended packaging change * Remove pch to try to reduce disk usage in build * Enable WPM Client Telemetry for COM Calls and Update Projects settings for succsesful inclusion in DesktopAppInstaller solution * Add error mapping. * Idl changes and error catching. * Try using PackageES for build for disk space * Rename the experimental feature. * Revert pipeline test. * Drop ARM from builds * Use details to open source instead of name * Fix source list updatetime metadata saving Co-authored-by: Santosh Chintalapati <sachinta@ntdev.microsoft.com> Co-authored-by: JohnMcPMS <johnmcp@microsoft.com>
Description of the new feature/enhancement
The Windows Package Manager currently exposes a command line interface to search for packages, install them, view progress, and more. This request is for a COM API so that callers have a more programmable way to make use of that functionality. The COM API would be preferred by callers that want to receive progress and completion events, and UWP packages that do not have permission to launch command line processes.
Proposed technical implementation details (optional)
The winget package could expose an out of proc COM server with an API surface that allows install of packages.
UWP apps and other callers would use the COM server to activate the objects.
The calling apps would include the winmd of the API in their project in order to handle marshalling data between processes.
The text was updated successfully, but these errors were encountered: