Best practice for reducing bloat with a helper/utility library for multiple projects

Question

Ok, I have an application that I have developed, let's call it Project A. Functions not found in the Microsoft .NET Framework I put into a shared library, let's call this MyLib.

Now Project B, C, D, E also uses MyLib (a lot of projects). My "MyLib" has been slowly added to for 4 or 5 years now.

Problem I now have is MyLib is huge. Well, 5MB, but I call that huge.

Question I have is should I, can I, and how can I compile my projects with MyLib but strip away non-used functions, classes, etc from MyLib? It rather blows that my Hello World apps, that use 1 tiny static function from MyLib results in a 6MB HelloWorld.exe (after ilmerge).

FOSS > Payware.

Answer 1

What you are searching for is the Mono Linker and it's source code is on GitHub. The standalone tool isn't used often but as it's one step of their iPhone compiler i guess that the libs are rock-solid.

Because you don't always use every feature of the libraries you are using for your program. By using the linker, you can reduce the size of what you have to distribute to your users.

Answer 2

Its looks like you need to group you library functions into smaller sections. Rather than take your cumbersome swiss army knife. Just break it down in to smaller parts.

"Best practice" would be to cover your mylib with unit tests and slowly refactor those classes apart.

"Best Practice" would be split those up. Look at the .net framework. There is not one huge dot.dll

Answer 3

Take some cues from the .Net framework itself. If MyLib has a lot of Text helper objects and functions along with a lot of say Web helper objects and functions split them into two separate projects and namespaces.

Of course, I only recommend this because it seems to bother you. Personally I have much bigger pet peeves than a few slightly oversized DLLs.

Since you say it's making VS run slower I assume you mean that you're including the project MyLib and not just the DLL. I would stop doing this immediately. Run a build of MyLib and simply include a reference to the DLL.

Answer 4

AFAIK, there's only the painfull way: Split up your library into functional parts. This will mean going through the various projects that consume MyLib and add the appropriate new references, but I don't see an other way. And that's also the tricky part: Deciding the boundaries of those functional units. If you're not careful, you might end up with (i.e.) referencing 6 different assemblies, where there previously was only one, worsening things along the way.

Evaluate very careful what your projects use and don't use, before you go down this path.