Moved classes from one library to another=> Client app does not recognize the change without recompiling

Question

We have a huge set of apps that use a library called Auth.dll. This library is allways is installed in the GAC of our servers.

Now we are refactoring it, so we have split Auth.dll in two new ones

• OAuth.dll
• LegacyAuth.dll

When we deploy the refactored libraries (without recompiling the client apps) we get that they are not able to find the classes, because they have moved from Auth.dll to OAuth.dll. We made a mistake in assuming that respecting namespaces and class design would work

What do we need to do in order to accomplish refactoring Auth.dll, and library code file structure, without needing to recompile client apps?

Is there a better way to accomplish this than to do the following?

---

We are able to get these three libraries.

1. OAuth.dll
2. LegacyAuth.dll
3. Auth.dll

We use inheritance in Auth.dll to reflect the refactored functionality that now is resides in the other libraries.

Note: Most of the classes that I am moving are structured like this:

public class UserEntity     
{   
   static public UserEntity FindByNif( string nif )
   {
        UserEntity ent = ....//operations;
        return ent;
   }
}

They return instances of the class itself

Answer 1

You can not. It's not possible to do this without recompiling the client apps.

You might in the future build your client apps so dynamic that this would be possible, but not only would you need to recompile them to do that as well, but the effort doing this is much larger than just recompiling when you change your Auth libraries.

I suggest you write Unit tests before refactoring, so you will see when you introduce breaking changes in your code.

---

Assuming you'd do it all over from scratch, you could implement a factory pattern in your original library, so you only need to adjust the original library to return a different instance for your required interface and your client apps would only know the interface and have no need to be recompiled. However, that's what you should have done with hindsight. I'm afraid it's of no practical help for your current situation.

Answer 2

Here is an idea I did not try by myself, but in theory it could work:

• provide a new version of Auth.dll, still containing all required classes, but implement them as adapters to the new classes OAuth.dll or LegacyAuth.dll. The adapters must be "interface compatible" to the former class versions (the public methods with their signatures must stay the same).

• use assembly binding redirection (like described in this older SO post) to make the dependent applications load the new DLLs.

The second step requires to provide to deploy a new app.config for each of the apps, but no recompiling. However, you should ask yourself why you consider recompiling and redeploying such a big problem - these are steps which can (and should) be possible in a mostly automated way, otherwise you won't be able to quickly deploy any severe bugfixes which require a full redeployment.

To your edit: such an adapter could look like this:

namespace Auth
{
    public class UserEntity     
    {   
       OAuth.UserEntity oaUserEntity;
       public UserEntity(OAuth.UserEntity oaUserEntity)
       {
           this.oaUserEntity=oaUserEntity;
       }
       static public UserEntity FindByNif( string nif )
       {
            // delegate the logic to the new class implementation
            OAuth.UserEntity ent = OAuth.UserEntity.FindByNif(nif);
            return new UserEntity(ent);
       }
       // another example:
       public int SomeMethod()
       {
            return this.oaUserEntity.SomeMethod();
       }
    }
 }