使用多个项目的帮助程序/实用程序库减少膨胀的最佳实践
好的，我开发了一个应用程序，我们将其称为项目 A。在 Microsoft .NET Framework 中找不到的功能我放入了共享库中，我们将其称为 MyLib。
现在项目B、C、D、E也使用MyLib（很多项目）。我的“MyLib”已经慢慢添加了四五年了。
我现在遇到的问题是 MyLib 太大了。嗯，5MB，但我称那是巨大的。
我的问题是我应该、可以吗？如何使用 MyLib 编译我的项目但从 MyLib 中删除未使用的函数、类等？令人震惊的是，我的 Hello World 应用程序使用 MyLib 中的 1 个微小静态函数，结果生成了 6MB 的 HelloWorld.exe（在 ilmerge 后）。
自由软件付费软件。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您正在搜索的是Mono Linker，它是源代码位于 GitHub 上。这个独立的工具并不经常使用，但由于它是他们的 iPhone 编译器的一步，我猜这些库是坚如磐石的。
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.
看起来您需要将库函数分组为更小的部分。而不是拿你笨重的瑞士军刀。只需将其分解为更小的部分即可。
“最佳实践”是用单元测试覆盖你的 mylib，并慢慢地重构这些类。
“最佳实践”将把它们分开。看看.net框架。没有一个巨大的dot.dll
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
AFAIK，只有痛苦的方法：将你的库分成功能部分。这意味着要遍历使用 MyLib 的各种项目并添加适当的新引用，但我没有看到其他方法。这也是棘手的部分：确定这些功能单元的边界。如果您不小心，您最终可能会引用 6 个不同的程序集，而之前只有一个程序集，从而使事情变得更糟。
在走这条路之前，非常仔细评估您的项目使用和不使用的内容。
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.
从 .Net 框架本身中获取一些线索。如果 MyLib 有很多 Text 帮助器对象和函数以及很多 Web 帮助器对象和函数，则将它们分成两个单独的项目和命名空间。
当然，我推荐这个只是因为它似乎让你感到困扰。就我个人而言，我对一些稍大的 DLL 的烦恼要大得多。
既然你说它使 VS 运行得更慢，我假设你的意思是你包含了项目 MyLib 而不仅仅是 DLL。我会立即停止这样做。运行 MyLib 的构建并简单地包含对 DLL 的引用。
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.