为什么 AppDomainSetup.ShadowCopyFiles 是一个字符串?

发布于 2024-08-13 08:02:55 字数 958 浏览 1 评论 0原文

来自文档

包含字符串值“true”的字符串,表示卷影复制已打开;或“false”表示卷影复制已关闭。

从 1.1 开始就是这样。任何人都可以阐明吗?

为了更好地衡量,我对 getter 和 setter 进行了反射:

public string ShadowCopyFiles
{
    get
    {
        return this.Value[8];
    }
    set
    {
        if ((value != null) && (string.Compare(value, "true", StringComparison.OrdinalIgnoreCase) == 0))
        {
            this.Value[8] = value;
        }
        else
        {
            this.Value[8] = null;
        }
    }
}

//The referenced Value property...

internal string[] Value
{
    get
    {
        if (this._Entries == null)
        {
            this._Entries = new string[0x10];
        }
        return this._Entries;
    }
}

private string[] _Entries; 

所以也许 Value 数组会产生一个更简单的复制构造函数或其他东西?

From the documentation:

A String containing the string value "true" to indicate that shadow copying is turned on; or "false" to indicate that shadow copying is turned off.

And its been this way since 1.1. Can anyone shed any light?

I reflector'd the getter and setter for good measure:

public string ShadowCopyFiles
{
    get
    {
        return this.Value[8];
    }
    set
    {
        if ((value != null) && (string.Compare(value, "true", StringComparison.OrdinalIgnoreCase) == 0))
        {
            this.Value[8] = value;
        }
        else
        {
            this.Value[8] = null;
        }
    }
}

//The referenced Value property...

internal string[] Value
{
    get
    {
        if (this._Entries == null)
        {
            this._Entries = new string[0x10];
        }
        return this._Entries;
    }
}

private string[] _Entries; 

So maybe the Value array begets an easier copy constructor or something?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

我做我的改变 2024-08-20 08:02:55

缺乏咖啡因。有些事情是不应该被理解的。

这显然似乎是 .NET 第一个版本中的错误,未修复,因为这可能会破坏“遗留”代码。

天哪,我刚刚发现了这个:

感谢您对 .NET Framework 的反馈!我们同意这是一个疏忽,并且属性类型应该是布尔值。然而,在向后兼容的版本(例如 Orcas)中进行此更改非常困难(如果不是不可能的话),因为我们会破坏任何依赖于字符串比较的客户的代码。因此,不幸的是,我们必须权衡破坏兼容性的风险与 API 清洁度的好处……当谈到最好地支持我们的客户群时,前者通常会获胜。我们将在内部跟踪这一点,将其视为需要改进的一件好事,并将在未来的版本中继续考虑这一点。

来自此处

Lack of caffeine. Some things are not meant to be understood.

This clearly seems to be a mistake from .NET first version, not fixed because that could break "legacy" code.

Gosh, I just found this:

Thanks for your feedback on the .NET Framework! We agree that this is an oversight and that the property type should be a boolean. However, it is quite difficult (if not impossible) to make this change in a backwards compatible release (such as Orcas), because we would break the code of any customer relying on string comparisons. So unfortunately we must weigh the risk of breaking compatibility vs. the benefits of API cleanliness...and when it comes to best supporting our customer base, the former typically wins. We will track this internally as a good thing to improve and we'll continue to consider it in future releases.

From here

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文