【问题标题】:Unqualified Class Name Collides with New .NET Class in System Namespace不合格的类名与系统命名空间中的新 .NET 类冲突
【发布时间】:2016-02-29 22:17:54
【问题描述】:

我有(很多)引用我的一个静态类的旧代码,称为AppContext。可悲的是,在这个遗留代码中,对这个类的引用都被一个命名空间using 声明解决了。为了争论起见,假设命名空间是“MyNamespace”(不是,但同样糟糕)

因此,我有很多很多模块,一开始看起来像这样:

using System;
using MyNamespace;

我现在的问题是微软在他们的 .NET Framework 4.6 中引入了一个新的System.AppContext 类。显然,我所有的代码都使用System

现在每当我遇到如下代码行时:

if (AppContext.MyProperty == "some value")

...我会收到一条错误消息,告诉我 MyProperty 不是 AppContext 的公认成员。

现在,随着我的用户推出包含 .NET 4.6(或 .NET 4.6.1)的 Windows 更新,我发现我的分布式代码到处都是。

我知道我对此的强力解决方案是去我引用我的类的每个地方并应用一个明确的命名空间。这是一件明智的事情,我会继续这样做。我的问题是我有一个庞大的安装基础,并且为每个人解决这个问题需要大量的时间和大量的工作(特别是考虑到回归测试/转向生产等)

除了为我的类的每个引用添加明确的命名空间之外,有什么方法可以解决名称冲突?

我真的很想知道是否有一个快速/短期的解决方案,我可以使用它来防止我的用户使用 Windows 更新破坏我的系统,直到我可以在任何地方推出适当的解决方案。

【问题讨论】:

    标签: c# .net namespaces


    【解决方案1】:

    using AppContext = MyNamespace.AppContext 添加到每个文件的顶部。

    【讨论】:

    • 谢谢 (+1)。类型别名在很大程度上会有所帮助,因为我可以在每个代码文件的顶部进行一次更改,而不是更改对静态类 (AppContext) 的每个引用。我希望还有其他可以做的事情,也许是在装配级别。我有数百个代码文件要处理。我正在寻找一个非常快速的停止间隙,以避免尽可能多的生产中断。
    猜你喜欢
    • 2011-12-30
    • 1970-01-01
    • 2018-12-09
    • 1970-01-01
    • 2014-07-01
    • 2021-11-22
    • 1970-01-01
    • 2013-12-11
    • 2015-12-16
    相关资源
    最近更新 更多