在非Cmdlet继承类中使用WriteError和WriteVerbose的问题

这个问题我之前帮别人排查过，确实挺容易卡壳的——毕竟自定义类没继承Cmdlet，直接拿不到那些WriteWarning、WriteError之类的输出方法对吧？给你几个实用的解决思路，亲测有效：

1. 直接传递Cmdlet实例给自定义类（最直观） #

这是最简单的方案，把当前Cmdlet的实例通过构造函数传给自定义类，让它直接调用Cmdlet的输出方法：

// 你的自定义业务类
public class MyCustomService
{
    private readonly PSCmdlet _parentCmdlet;

    // 构造函数接收Cmdlet实例
    public MyCustomService(PSCmdlet cmdlet)
    {
        _parentCmdlet = cmdlet;
    }

    public void ExecuteBusinessLogic()
    {
        // 调用Cmdlet的警告输出
        _parentCmdlet.WriteWarning("自定义类触发的警告信息");
        
        // 调用详细日志输出（会自动遵守用户的VerbosePreference设置）
        _parentCmdlet.WriteVerbose("自定义类的执行细节日志");

        // 构造并输出错误信息
        var error = new ErrorRecord(
            new InvalidOperationException("自定义业务逻辑出错了"),
            "BusinessLogicError",
            ErrorCategory.InvalidOperation,
            this);
        _parentCmdlet.WriteError(error);
    }
}

// 你的Cmdlet实现类
[Cmdlet(VerbsDiagnostic.Test, "CustomClassOutput")]
public class TestCustomClassOutputCommand : PSCmdlet
{
    protected override void ProcessRecord()
    {
        // 实例化自定义类时传入当前Cmdlet实例
        var service = new MyCustomService(this);
        service.ExecuteBusinessLogic();
    }
}

这个方案几乎不需要额外改造，自定义类能完全复用Cmdlet的输出逻辑，包括自动遵守用户设置的VerbosePreference、WarningPreference等，非常省心。

2. 注入ICommandRuntime接口（更解耦） #

如果不想让自定义类直接依赖PSCmdlet类型（比如要做单元测试），可以用PowerShell提供的ICommandRuntime接口——Cmdlet的所有输出方法本质上都是调用这个接口的实现：

public class MyCustomService
{
    private readonly ICommandRuntime _commandRuntime;

    public MyCustomService(ICommandRuntime commandRuntime)
    {
        _commandRuntime = commandRuntime;
    }

    public void ExecuteBusinessLogic()
    {
        _commandRuntime.WriteWarning("解耦后的警告输出");
        _commandRuntime.WriteVerbose("解耦后的详细日志");
    }
}

// Cmdlet中调用
protected override void ProcessRecord()
{
    // 传入当前Cmdlet的CommandRuntime属性
    var service = new MyCustomService(this.CommandRuntime);
    service.ExecuteBusinessLogic();
}

这样自定义类只依赖抽象接口，和具体的Cmdlet实现解耦，后续写单元测试时可以模拟ICommandRuntime来验证输出逻辑，灵活性更高。

3. 谨慎使用全局PowerShell宿主（不推荐首选） #

还有一种方式是直接获取全局的PowerShell宿主对象，但这个方法要谨慎使用——因为在多线程、非交互式环境或者嵌套PowerShell会话中，全局宿主可能和当前Cmdlet的上下文不一致，而且需要手动处理输出偏好设置：

public class MyCustomService
{
    public void ExecuteBusinessLogic()
    {
        // 获取全局PSHost
        var host = System.Management.Automation.PowerShell.Create()
            .Runspace.SessionStateProxy.PSVariable.GetValue("Host") 
            as System.Management.Automation.Host.PSHost;
        
        host.UI.WriteWarningLine("全局宿主输出的警告");

        // 手动检查Verbose偏好是否开启
        var verbosePref = System.Management.Automation.PowerShell.Create()
            .Runspace.SessionStateProxy.PSVariable.GetValue("VerbosePreference") 
            as ActionPreference?;
        
        if (verbosePref == ActionPreference.Continue)
        {
            host.UI.WriteVerboseLine("全局宿主输出的详细日志");
        }
    }
}

这个方案的缺点很明显：上下文不可靠，还要自己处理各种偏好设置，除非特殊场景，否则不建议用。

内容的提问来源于stack exchange，提问作者another_one