Showing failures and log info in config flow; Fixing 'cloudpc-app' popup

[huzaifa-d]

Summary of the issues

1. The configuration flow for Dev Boxes didn't show any failures since the API didn't support it.
2. The extension launches a popup if Windows App isn't installed
   

Detailed description of the pull request / Additional comments

1. The Dev Box configuration has been fixed and the API now correctly sends a "Failure" status. The extension has been changed accordingly to show the status on the UI. Additionally, a log API is called for the raw log, parsed and the relevant error line is now sent back to Dev Home to be shown on the UI.

2. The extension now checks to see if Windows App is installed before trying to try associated protocol launches

Validation steps performed

Tested the configuration flow on various Dev Boxes

PR checklist

• Closes Customization flow needs to handle failure once supported #157
• Closes #Error: Get an app to open this 'ms-cloudpc'... devhome#2902
• Tests added/passed
• Documentation updated

[safmswork]

I don't understand, how is DevHome calling these functions if GetOperations() within this file doesn't return PinToStartMenu and PinToTaskbar? From reading the code it seems to me like they should be blocked from getting called from DevHome? What am I missing?

[huzaifa-d]

GetIsPinnedToStartMenuAsync() is the function that gets called. Does that make sense?

[bbonaby]

@safmswork I believe its due to the GetPinStatusAsync method call. In that method we still call into the WindowsApp protocol launch here:

DevHomeAzureExtension/src/AzureExtension/DevBox/DevBoxInstance.cs

Line 759 in e9cd160

Process? p = Process.Start(psi);

**Edit: Oh misunderstood what you meant, but I see what you mean, we have a check in Dev Home which should prevent these calls. Perhaps there is something going on where users have multiple azure extensions installed? **

[safmswork]

Right, but who calls GetPinStatusAsync? The only one is GetIsPinnedToStartMenuAsync and GetIsPinnedToTaskbarAsync . And Devhome only calls those if:
if (supportedOperations.HasFlag(ComputeSystemOperations.PinToTaskbar))

[bbonaby]

Hmm I guess we need to confirm if the versioning method is returning the correct value. Assuming Huzaifa and Kevin don't have a version that should support pinning. Then they will have the pinning operations. Which would then make GetPinStatusAsync and the other methods callable from Dev Home. Which would lead to the computer not being able to protocol launch this:

DevHomeAzureExtension/src/AzureExtension/DevBox/DevBoxInstance.cs

Line 75 in e9cd160

private static readonly CompositeFormat ProtocolPinString = CompositeFormat.Parse("ms-cloudpc:pin?location={0}&request={1}&cpcid={2}&workspaceName={3}&environment={4}&username={5}&version=0.0&source=DevHome");

So we just need to get what version of Windows app they're using

[safmswork]

Maybe that's it, maybe the WindowsApp version that I hardcoded into MinimumWindowsAppVersion is wrong somehow. @huzaifa-d what version of WindowsApp did you get the repro on?

[bbonaby]

Spoke to Safet offline, issue is Dev Home related where we call https://github.com/microsoft/devhome/blob/4b071cfe01b78af6e6ec8a711b796a189f53298b/tools/Environments/DevHome.Environments/ViewModels/ComputeSystemViewModel.cs#L189

which leads us to call:

https://github.com/microsoft/devhome/blob/4b071cfe01b78af6e6ec8a711b796a189f53298b/tools/Environments/DevHome.Environments/ViewModels/ComputeSystemViewModel.cs#L138

and

https://github.com/microsoft/devhome/blob/4b071cfe01b78af6e6ec8a711b796a189f53298b/tools/Environments/DevHome.Environments/ViewModels/ComputeSystemViewModel.cs#L139

without checking the enum flags. I'll update it in my PR in dev home

[safmswork]

Do we still want to check in this change? Thoughts?

[bbonaby]

Hey yea I think its fine, to have the extra check, just for safety now that we have found the issue to be a dev home issue and not really an azure extension issue. So I think this is ok.

[sshilov7]

General note: while we can check the enum flag in Dev Home there are always races that can happen due to multi-leg cross-process communication. We can get a flag saying that some operation is supported at the time of the check, but by the time of the next call to the extension the operation may not be supported anymore. So, both sides should handle this situation gracefully and not blame the other side that the call should never happen or that the operation status was reported incorrectly.