¿Cuáles son las mejores prácticas para eliminar el código obsoleto?

Tengo la necesidad de eliminar un método obsoleto. Soy consciente del [Obsolete]atributo. ¿Tiene Microsoft una guía recomendada de mejores prácticas para hacer esto?

Aquí está mi plan actual:

R. No quiero crear un nuevo ensamblaje porque los desarrolladores tendrían que agregar una nueva referencia a sus proyectos y espero recibir mucho dolor de mi jefe y compañeros de trabajo si deben hacerlo. Tampoco mantenemos múltiples versiones de ensamblaje. Solo usamos la última versión. Cambiar esta práctica requeriría cambiar nuestro proceso de implementación, lo cual es un gran problema (hay que enseñar a las personas cómo hacer cosas con TFS en lugar de FinalBuilder y hacer que abandonen FinalBuilder)

B. Marque el viejo método como obsoleto.

C. Debido a que la implementación está cambiando (no la firma del método), necesito cambiar el nombre del método en lugar de crear una sobrecarga. Entonces, para que los usuarios conozcan el método adecuado, planeo agregar un mensaje al [Obsolete]atributo. Esta parte me molesta, porque el único cambio que estoy haciendo es desacoplar el método de la cadena de conexión. Pero, como no estoy agregando un nuevo ensamblaje, no veo forma de evitar esto.

Resultado:

[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 utiliza el atributo [obsoleto] para informar a los desarrolladores que el método, la propiedad o la clase están en desuso y que pueden modificarse (o no admitirse) en futuras versiones.

Eso le brinda al menos un ciclo de lanzamiento para notificar a los usuarios de su API que su función está "desapareciendo" y para eliminar referencias a ella en futuras versiones de su software.

El tiempo que dejes la característica original depende de ti. Si desea "alentar encarecidamente" a los desarrolladores a que usen sus nuevas funciones en lugar de las anteriores, solo necesita un ciclo de lanzamiento adicional para eliminarlo. Si tiene la intención de tener una compatibilidad con versiones anteriores permanente, puede dejarla para siempre.

Como señala Brian, si solo está cambiando la implementación subyacente, pero no la firma del método, es posible que no necesite hacer nada de esto.

Debido a que la implementación está cambiando (no la firma del método), necesito cambiar el nombre del método en lugar de crear una sobrecarga.

No entiendo. Si la implementación está cambiando pero la firma no, ¿por qué harías esto? Deje que el método "antiguo" use la implementación nueva y mejorada. Todos los desarrolladores que consuman esta API rodarán los ojos cuando vean un método con la misma firma creada y advertencias de desaprobación en sus llamadas a métodos existentes. (¿Puedes pensar en alguna vez que esto haya sucedido en una API?)

Si no está seguro de si cambiar la implementación subyacente de este método funcionará, verifique el comportamiento con pruebas unitarias antes y después de cambiar la implementación.