I'm working on a C# app that makes use of interop to interact with several of our DLLs that export C-linkage functions. Because our product consists of more than one executable, I moved all the interop code and many shared classes into a C# class library, and reference it in the C# executable projects.

I'm considering breaking this monolithic C# class library up into a few, more granular class libraries for a few reasons, including:

• When I initially set this up, it was less clear which executable projects would need which classes. The app has matured somewhat since then, and it's now clear that a significant percentage of the classes in the library are only used by a single executable...
• Our C-linkage DLLs have dependencies that very occasionally fail on a user machine[1]. That prevents all our executables from running, even the ones that don't make use of that particular DLL.
• Startup time for our primary app is high (> 2 seconds). As soon as we use anything in our .NET class library, (I think) it loads everything (DLLs included).

My question is about the factors to consider before deciding whether to stay with a single class library, or break things up into smaller, more independent libraries. For example, is the per-library overhead in (runtime) resource footprint or loading time significant enough to affect the decision?

[1]: If they have a broken driver install, for example.