淘汰过时的代码的最佳实践是什么？

我需要淘汰一种过时的方法。我知道这个[Obsolete]属性。Microsoft是否有推荐的最佳实践指南来执行此操作？

这是我目前的计划：

答：我不想创建一个新的程序集，因为开发人员将不得不为其项目添加新的引用，并且我希望如果老板和同事必须这样做，将会引起很多痛苦。我们也不维护多个程序集版本。我们仅使用最新版本。更改此做法将需要更改我们的部署过程，这是一个大问题（必须教人们如何使用TFS而不是FinalBuilder来做事情，并让他们放弃FinalBuilder）

B.标记旧方法已过时。

C.因为实现正在更改（不是方法签名），所以我需要重命名方法而不是创建重载。因此，为了使用户知道正确的方法，我计划向[Obsolete]属性添加一条消息。这部分让我感到困扰，因为我所做的唯一更改就是将方法与连接字符串分离。但是，由于我没有添加新的程序集，因此无法解决此问题。

结果：

[Obsolete("Please don't use this anymore because it does not implement IMyDbProvider.  Use XXX instead.")];
        /// <summary>
        /// 
        /// </summary>
        /// <param name="settingName"></param>
        /// <returns></returns>
        public static Dictionary<string, Setting> ReadSettings(string settingName)
        {
            return ReadSettings(settingName, SomeGeneralClass.ConnectionString);
        }

        public Dictionary<string, Setting> ReadSettings2(string settingName)
        {
            return ReadSettings(settingName);// IMyDbProvider.ConnectionString private member added to class.  Probably have to make this an instance method.
        }

Microsoft使用[obsolete]属性来告诉开发人员该方法，属性或类已弃用，并且在将来的发行版中可能会更改（或根本不支持）。

这给了您至少一个发布周期，以通知您的API用户其功能正在“消失”，并在其软件的将来版本中删除对该功能的引用。

您将原始功能保留多长时间完全取决于您。如果您想“强烈鼓励”开发人员在旧功能上使用您的新功能，则只需一个额外的发布周期即可将其删除。如果您打算具有永久的向后兼容性，则可以永久保留。

正如Brian指出的那样，如果仅更改基础实现而不是方法签名，则可能根本不需要执行任何操作。

因为实现正在更改（不是方法签名），所以我需要重命名方法而不是创建重载。

我不明白 如果实现改变了但签名没有改变，为什么要这么做呢？让“旧”方法使用新的和改进的实现。使用此API的所有开发人员都将在看到具有完全相同的签名创建的方法并在其现有方法调用上弃用警告的情况下转眼。（您能想到API曾经发生过的时间吗？）

如果不确定更改此方法的基础实现是否可行，请在更改实现之前和之后使用单元测试验证行为。