cmdlet 如何知道何时真正应该调用 WriteVerbose()? [英] How does a cmdlet know when it really should call WriteVerbose()?

查看:19
本文介绍了cmdlet 如何知道何时真正应该调用 WriteVerbose()?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

cmdlet 如何知道它真正何时应该调用WriteVerbose()WriteDebug() 等等?

How does a cmdlet know when it really should call WriteVerbose(), WriteDebug() and etc.?

也许我错过了一些简单的事情,但我找不到答案.所有 cmdlet到目前为止我看到的实现只是调用 WriteVerbose() 而没有任何犹豫.我知道这样做正确,但它有效.

Perhaps I miss something simple but I cannot find the answer. All cmdlet implementations I have seen so far just call WriteVerbose() without any hesitation. I know that it is correct to do so, but it is not effective.

当详细模式关闭但 cmdlet 仍在准备时,性能会受到影响WriteVerbose() 调用的数据,也就是说,什么都不做.

Performance suffers when verbose mode is off but a cmdlet still prepares data for WriteVerbose() call, that is, for nothing.

换句话说,在 cmdlet 中,我希望能够:

In other words, in a cmdlet I would like to be able to:

if (<VerboseMode>)
{
    .... data preparation, sometimes expensive ...
    WriteVerbose(...);
}

但我不知道如何获得这个 if ().有什么想法吗?

But I don't know how to get this if (<VerboseMode>). Any ideas?

结论:@stej 的回答展示了如何从理论上获取所需的信息.在实践中,这是hacky,不太可能合适.因此,如果 cmdlet 产生非常昂贵的详细或调试输出,那么引入一个指定详细级别的附加参数看起来是合理的.

Conclusion: The @stej’s answer shows how get the required information in theory. In practice this is hacky and unlikely suitable. Thus, if a cmdlet produces really expensive verbose or debug output then it looks reasonable to introduce an additional parameter specifying verbosity levels.

推荐答案

这是来自 System.Management.Automation.MshCommandRuntime 的方法.

internal void WriteVerbose(VerboseRecord record)
{
    if ((this.Host == null) || (this.Host.UI == null))
    {
        tracer.TraceError("No host in CommandBase.WriteVerbose()", new object[0]);
        throw tracer.NewInvalidOperationException();
    }
    ActionPreference verbosePreference = this.VerbosePreference;
    if (this.WriteHelper_ShouldWrite(verbosePreference, this.lastVerboseContinueStatus))
    {
        if (record.InvocationInfo == null)
        {
            record.SetInvocationInfo(this.MyInvocation);
        }
        this.CBhost.InternalUI.WriteVerboseRecord(record);
    }
    this.lastVerboseContinueStatus = this.WriteHelper(null, null, verbosePreference, this.lastVerboseContinueStatus, "VerbosePreference");
}

MshCommandRuntime 实现了接口 ICommandRuntime,它对详细程度一无所知:|(通过反射器发现).MshCommandRuntime 的实例应该在 Cmdlet 中可用(public ICommandRuntime CommandRuntime { get; set; }).

MshCommandRuntime implements interface ICommandRuntime which doesn't know anything about verbosity :| (found through reflector). Instance of MshCommandRuntime should be available in Cmdlet (public ICommandRuntime CommandRuntime { get; set; }).

因此应该可以将属性 CommandRuntime 转换为 MshCommandRuntime 并检查详细程度.总之,这真的很丑.

So it should be possible to cast property CommandRuntime to MshCommandRuntime and check the verbosity. Anyway, this is really ugly.

我完全同意应该有一个简单的方法来找到它.此外,(做梦的)编译器应该足够聪明,不会在这样的情况下评估某些字符串:

I totally agree that there should be an easy way how to find it out. And besides that (dreaming) compiler should be clever enough not to evaluate some strings in cases like this:

$DebugPreference = 'SilentlyContinue'
$array = 1..1000
Write-Debug "my array is $array"

Write-Debug 的输入永远不会被使用,所以 $array 不应该在传递的字符串中求值..(可以测试它真的是评估如下:Write-Debug "my array is $($array|%{write-host $_; $_})"

Input to Write-Debug will be never used, so $array shouldn't be evaluated in passed string.. (it is possible to test that it is really evaluated like this: Write-Debug "my array is $($array|%{write-host $_; $_})"

这篇关于cmdlet 如何知道何时真正应该调用 WriteVerbose()?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆