Enable parameter injection for Azure PowerShell response

[daxian-dbw]

PR Summary

This PR enables parameter injection for responses from the Azure PowerShell handler.

• Supporting parameter injection for Azure PowerShell response requires to have PowerShell runtime available. However, pulling PowerShell dependencies at the agent level doesn't work because an agent gets loaded to its own AssemblyLoadContext, while PowerShell runtime has to live in the default AssemblyLoadContext. The solution is to make AIShell depend on PowerShell SDK so that the PowerShell dependencies are moved to the application level and are loaded into the default AssemblyLoadContext. With that, any agent can use PowerShell without needing to pull PowerShell dependency assemblies into the agent's folder.
• Updated the build script to properly deploy the PowerShell modules. They need to be placed in the same folder where System.Management.Automation.dll is located, AKA $PSHOME.
• Updated AgentAssemblyLoadContext to make it able to load assemblies and native libs from the runtimes folder under the agent folder.
• Updated the instruction prompt a bit to ask a placeholder to always be enclosed in double quotes. This is because today we want the placeholder to be represented in the <xxx> form, but the character > is a special operator in PowerShell and hence causing parsing issue.
• Introduced a PowerShell pool implementation, which is simple and tiny. The pool is created and populated with PowerShell instances (3 by default) in the background as early as the DataRetriever type gets initialized, so that when we need a PowerShell instance to perform parameter injection work for a AzPS command, it's likely one will be already available.
• Method PairPlaceholdersForPSCode is for looking for the command and parameter for a given placeholder for AzPS script. Sometimes the AzPS script first assigns all placeholder values to variables and then use those variables as arguments in commands. The method handles that case too.
• Method GetArgValuesForAzPS is for retrieving argument values for the given command and parameter. It depends on argument completion support in Azure PowerShell.

Pending issue

I ran into an issue with the completer attribute LocationCompleterAttribute in Azure PowerShell:

• The LocationCompleterAttribute used for many -Location parameters always time out because it takes ~10 seconds for the first call to get back results.

The issue has been reported to @wyunchi-ms, who is working on improving its performance and hopefully will have it fixed in the next Az PowerShell release.

Follow-up tasks

• Add unit tests for methods in DataRetriever and other types to cover the scenarios we support.
• Add logging and maybe telemetry based on feedback.
• What if the user doesn't have the necessary Az module installed? Today I assume all needed Az modules are available, but we should handle the case when any are not, in an intuitive way.

Tracked by #342

[daxian-dbw]

@wangzelin007 can you please also review the changes? I cannot add you directly as a reviewer yet as you haven't accept the invite to become a contributor to this repo.

[Copilot]

Copilot reviewed 5 out of 9 changed files in this pull request and generated no comments.

Files not reviewed (4)

• build.psm1: Language not supported
• shell/AIShell.App/AIShell.App.csproj: Language not supported
• shell/agents/Microsoft.Azure.Agent/Microsoft.Azure.Agent.csproj: Language not supported
• shell/agents/Microsoft.Azure.Agent/AzureAgent.cs: Evaluated as low risk

Comments suppressed due to low confidence (3)

shell/agents/Microsoft.Azure.Agent/DataRetriever.cs:389

• [nitpick] The variable 'variable' is declared but not always used, which might lead to confusion. Consider utilizing it more clearly or removing it if not necessary.

VariableExpressionAst variable = null;

shell/agents/Microsoft.Azure.Agent/DataRetriever.cs:668

• The 'returnValues' list is initialized multiple times within the same method, which is inefficient. Consider initializing it once and reusing it.

List<string> returnValues = null;

shell/agents/Microsoft.Azure.Agent/DataRetriever.cs:654

• Ensure that all potential null values are adequately checked, especially in methods like 'GetArgValuesForAzPS'.

if (!cmdInfo.Parameters.TryGetValue(parameter, out ParameterMetadata paramMetadata))

[wangzelin007]

LGTM~

[wyunchi-ms]

LGTM~

[wyunchi-ms]

Do we plan to implement the wordToComplete in phase 2?

[daxian-dbw]

The wordToComplete is an empty string, so it matches everything.
Did you mean the "CommandAst" and "fakeBoundParameters" parameters? They are not used by all existing completer attributes in AzPS today, so I didn't bother passing them in. It's easy to get the CommandAst, but not for the fakeBoundParameters.