Quali sono le migliori pratiche per eliminare gradualmente il codice obsoleto?

Ho la necessità di eliminare gradualmente un metodo obsoleto. Sono a conoscenza [Obsolete]dell'attributo. Microsoft ha una guida di best practice consigliata per farlo?

Ecco il mio piano attuale:

R. Non voglio creare un nuovo assembly perché gli sviluppatori dovrebbero aggiungere un nuovo riferimento ai loro progetti e mi aspetto di ricevere molto dolore dal mio capo e dai miei colleghi se devono farlo. Inoltre non gestiamo più versioni di assiemi. Usiamo solo l'ultima versione. Cambiare questa pratica richiederebbe di cambiare il nostro processo di distribuzione che è un grosso problema (bisogna insegnare alle persone come fare le cose con TFS invece di FinalBuilder e convincere loro a rinunciare a FinalBuilder)

B. Contrassegna il vecchio metodo come obsoleto.

C. Poiché l'implementazione sta cambiando (non la firma del metodo), devo rinominare il metodo anziché creare un sovraccarico. Quindi, per rendere gli utenti consapevoli del metodo corretto, ho intenzione di aggiungere un messaggio [Obsolete]all'attributo. Questa parte mi disturba, perché l'unica modifica che sto facendo è il disaccoppiamento del metodo dalla stringa di connessione. Ma, poiché non sto aggiungendo un nuovo assembly, non vedo alcun modo per aggirare questo.

Risultato:

[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 utilizza l'attributo [obsoleto] per dire agli sviluppatori che il metodo, la proprietà o classe è deprecato, e possono essere modificate (o non supportati affatto) nelle versioni future.

Questo ti dà almeno un ciclo di rilascio per informare gli utenti della tua API che la loro funzionalità "sta scomparendo" e per rimuovere riferimenti ad essa nelle versioni future del loro software.

Per quanto tempo lasci la funzionalità originale dipende interamente da te. Se si desidera "incoraggiare fortemente" gli sviluppatori a utilizzare le nuove funzionalità rispetto a quelle precedenti, è necessario solo un ciclo di rilascio aggiuntivo per rimuoverlo. Se hai intenzione di avere una retrocompatibilità permanente, puoi lasciarla per sempre.

Come sottolinea Brian, se stai solo modificando l'implementazione sottostante, ma non la firma del metodo, potresti non dover fare nulla di tutto ciò.

Poiché l'implementazione sta cambiando (non la firma del metodo), ho bisogno di rinominare il metodo anziché creare un sovraccarico.

Non capisco. Se l'implementazione sta cambiando ma la firma non lo è, perché mai dovresti farlo? Consenti al metodo "vecchio" di utilizzare l'implementazione nuova e migliorata. Tutti gli sviluppatori che utilizzano questa API attireranno la loro attenzione quando vedranno un metodo con la stessa identica firma creata e avvisi di deprecazione sulle loro chiamate di metodo esistenti. (Riesci a pensare a un momento in cui è mai successo in un'API?)

Se non si è sicuri che la modifica dell'implementazione sottostante di questo metodo funzionerà, verificare il comportamento con unit test prima e dopo aver modificato l'implementazione.