Disambiguating a method during a .net library upgrade

One scenario I had recently, involved a method that was named in such a way that it wasn’t clear the effect it would have given the context. Of course, it came to attention because it was used expecting a different behavior. The upside is that it was detected during a focused integration test, so it was revealed very early in the involved scenario.

As the library is used in more than one project, this raised the question if the code could have been used in such way in any of the other projects. We decided on changing it so we could tell if this was the case during the build of any project that used the library.

Below code sample outlines the approach we used to update the library so developers involved review the usages to the now clearly named alternatives.

[Obsolete("Use ActionA or ActionB", true)]
public static void ActionThatWasntClearIfItDidAorB()
{
    ActionA();
}
public static void ActionA()
{
    // original code
}
public static void ActionB()
{
    // alternative code
}