At this point the obvious fix is to split the assembly into multiple smaller ones. Unfortunately, by then the single assembly is used on numerous projects. A major refactoring now requires extensive changes across all of these referencing applications. This realization usually stops any refactoring effort, leaving the utilities assembly to continue growing larger and more unwieldy.
To look at potential solutions, I've created a Utilities assembly with the following Logger class:
namespace Utilities {public class Logger
{public void LogError(string message)
{Debug.WriteLine("Error: " + message);
}
}
}
The goal is to move this class to a separate assembly called LoggingUtilities.
One solution is to use the TypeForwardedTo attribute. This is an assembly-level attribute that flags a specified class as having moved. To use this, I start by moving the Logger class to my new assembly. Note that I keep the same namespace as before - this is required for the forwarding to work.
Next I add a reference to LoggingUtilities within Utilities.
Finally, I open up AssemblyInfo.cs file in the Utilities project and add the following line:
[assembly: TypeForwardedTo(typeof(Utilities.Logger))]
If I recompile the dlls and drop them in a folder with my existing application, it will continue to function even though the class has been moved.
This takes care of keeping the current compiled code running, but what about future versions? If I open up the source for one of my applications and attempt to compile, I now receive errors stating "The type or namespace name 'Logger' could not be found." It seems the redirection works at runtime but not at compile time. For someone not familiar with the previous refactoring, this could prove an interesting issue to track down.
In my opinion, there is a far better solution than using the TypeForwardedTo attribute. Going back to the original code, this time I copy the code to the new assembly (as opposed to moving it.) On the copy I change the namespace to match my new assembly.
namespace LoggingUtilities {public class Logger
{public void LogError(string message)
{ Debug.WriteLine("Error: " + message);
}
}
}
In my original Logger class, I create an instance of my new Logger. Each method in the original class now forwards requests to the new Logger instance. In this way, I am wrapping the new class in the original. This allows applications to still use the old class, though the functionality has been moved.
public class Logger
{ LoggingUtilities.Logger _logger =new LoggingUtilities.Logger();
[Obsolete("Use LoggingUtilities.Logger instead")]
public void LogError(string message)
{_logger.LogError(message);
}
}
As before we need to evaluate referencing projects. Because our original class still exists, these applications will continue to compile.
Note that I've added an "Obsolete" attribute to the LogError method. This means we will receive a compiler warning (or error) that we need to change our application to use the new class. This makes it clear what needs to be modified, saving time on any rework.
