>>While having the framework all in a single DLL makes it easy for many reasons, it adds complications in others, as you've found. Other than being part of the framework, I don't see what creating a PDF has to do with ecommerce.
>
>The framework contains over 100 classes for most of today's business needs in regards to application deployment. This is installed nationwide. Some clients need 1/3 of the classes while others will use 2/3 and so on. Depending on their needs, they might have only Framework.dll and TheNameOfTheClientWebSite.dll in the bin directory or, with that, some additional DLLs that specific classes, if the application needs them, are using.
>
>No, there is no relationship between PDF and ecommerce. Those are two separate classes. They have been mentioned as an example of classes that are in needs of a specific DLL. I have about 4 or 5 in total that are tied into the framework which are useful for some of its classes.

So if I understand correctly, you have a EXE and a set of DLLs which, depending on the configuration, may or may not be required for a specific installation?
It may be a bit hard to retro-fit but you could look at using something like MEF so that the EXE could discover, load and use the DLLs that were included in the installation?