自动仅将托管c#类集合的引用组件链接到dll或应用程序中

本文关键字：链接 组件 引用 dll 应用程序 集合 | 更新日期: 2023-09-27 18:04:44

一个开发伙伴最近的不可协商的平台迁移迫使我使用Visual Studio 2008为Windows CE 6.0开发。net 3.5 Compact Framework。

在其他环境中，我习惯于聚合一个由"特性"类/模块等组成的大型框架。到一个静态库中，与较小的"产品配置"代码体链接，以便生成各种应用程序和/或动态库图像，其中仅包含实际引用的那些组件。

虽然静态链接是偶然的，但是对未使用代码的剪裁是至关重要的:它不仅满足了对足迹的关注，而且满足了市场中的安全需求，在这个市场中，客户将未使用的代码——特别是那些如果执行可能会增加功能的代码——视为不可接受的漏洞。

不幸的是，这似乎与。net世界观不一致(更不用说VS2008提供的解决方案和项目模板)，它似乎倾向于构建dll(程序集，类库，netmodule等)，以便通过整个部署来重用。事实上，支持这种方法的信息是如此之多，以至于我很快就会感到沮丧，试图找到任何相反的东西。

那么，能否实现与静态链接工件等效的死代码匹配效果?在静态链接中，对组件的源代码引用，加上对其聚合集合的产品或解决方案引用，足以确保所有和仅包含所需组件。

例如，像ILMerge这样的工具是否可以在没有显著的人工干预或维护开销(例如，客户端代码或框架库构建配置之外的组件列表)的情况下完成此任务，并且仅向面临更陡峭学习曲线的其他开发人员提供有限的解释?或者更好的是，是否有一些手段已经存在于VS2008?

,
egr

自动仅将托管c#类集合的引用组件链接到dll或应用程序中

是的，这样的工具是存在的，但是在。net中没有被广泛使用。

我之前提到过的一个工具是Remotesoft Salamander . net link。我没有使用过这个工具，所以除了他们的网站，我不能评论它的优点:

Salamander . net Linker和迷你部署工具允许您将。net程序集链接到一个文件中，并且无需安装整个Microsoft . net框架即可部署您的应用程序。链接器选择性地链接MSIL代码，只将所需的类和方法放在一起，并且它能够链接到Microsoft . net框架类库。

以下是我根据额外的研究和收到的评论和回答得出的结论:

  1. 如果不引入第三方工具，我公司的开发合作伙伴将拒绝支持，很明显，生产一个封闭的、充分利用的、与客户需求一致的子系统的唯一方法，可能是在构建配置中显式地管理最终产品程序集中包含的类集合，独立于其他类的引用。

  2. 为了避免容易出错的、手工的、并行的源代码修改，有必要在产品最终程序集中使引用类的存在或不存在足以启用或禁用它们支持的特性，而不留下可供利用的悬空引用。

  3. 暂时忽略悬空引用问题，我们想到了两种方法:使用反射来找到潜在的引用，这些引用实现了它们的潜在引用所知道的接口;或潜在的引用对象继承了具有引用类知识的基类。在任何一种情况下，引用者和被引用者都必须在同一个程序集中，并且该机制必须将自己限制在该程序集中。

  4. 因为我们的开发合作伙伴的系统架构不仅需要这个平台专用的托管的c# . net组件，还需要我们希望在他们的其他平台中重用的非托管的c++组件，而这些平台都没有包含c#/。NET也不允许RTTI，后一种方法似乎更明智，为了设计的一致性。

  5. 给定所选择的方法，在任何一种语言中，引用基类的一个很好的候选是嵌套在引用类中的基类(如果编译器不能将嵌套类视为成员，则c++中的友ed)。

  6. 关于悬空引用问题，如果有可能在程序集中不包含引用类，则可以在引用类中包含引用基类的实例(可能是静态的，可能是特殊处理的)，以避免引用和/或执行引用基类使用的引用接口失败(再次，客户将使用覆盖工具查找这一点)。

  7. 最后，由于合作伙伴的体系结构只要求我们的产品提供少量定义良好的接口，因此我们的绝大多数c#类将位于最终程序集的内部，因此实现了所需的分辨率限制。

——
egr

相关文章：