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

一个开发合作伙伴最近进行的不可协商的平台迁移迫使我使用Visual Studio 2008为Windows CE 6.0进行.NET 3.5 Compact Framework开发

在其他环境中，我习惯于将“功能”类/模块等的大型框架聚合到一个静态库中，与较小的“产品配置”代码体链接，以便生成各种应用程序和/或动态库映像，其中只包含实际引用的组件

虽然静态链接是偶然的，但对未使用代码的删减是至关重要的：它不仅满足了占地面积问题，而且满足了市场中的安全要求，在这种市场中，客户会看到未使用的代码，特别是那些如果作为不可接受的漏洞执行可能会增加功能的代码

不幸的是，这似乎与.NET worldview（更不用说VS2008提供的解决方案和项目模板）不一致，后者似乎倾向于构建DLL（程序集、类库、NetModule等），以便通过整体部署重用。事实上，支持这种方法的信息如此之多，以至于我在试图找到任何相反的东西时很快变得沮丧

因此，我能否实现与静态链接工件等效的死代码分割效果，其中对组件的源代码引用，加上对其聚合集合的产品或解决方案引用，足以确保部署中包含所有且仅包含所需的组件

例如，像这样的工具是否可以在不需要大量手动干预或维护开销（例如，除客户端代码或框架库构建配置外的组件列表）的情况下完成此任务，并且仅向面临更陡峭学习曲线的其他开发人员进行有限的解释；或者更好的是，VS2008中是否已经存在一些方法

--

---

egr

是的，这样的工具存在，但在.NET中没有广泛使用

我以前见过的一个工具是。我没有使用过这个工具，所以除了他们网站上的内容外，我无法评论它的优点：

---

Salamander.NET链接器和迷你部署工具允许您将.NET程序集链接到一个文件中，并在不安装整个Microsoft.NET Framework的情况下部署应用程序。链接器仅将所需的类和方法选择性地链接到MSIL代码，并且它能够链接到Microsoft.NET framework类库。

以下是我根据其他研究以及收到的评论和回答得出的结论：

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

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

暂时忽略悬而未决的引用问题，我们想到了两种方法：使用反射来寻找潜在的引用人，实现他们潜在的引用人已知的接口；或者让潜在的引用人继承一个具有referer类知识的基类。无论哪种情况，referer和referent都必须在同一个程序集中，并且机制必须将自身限制在该程序集中。

由于我们的开发伙伴的系统架构不仅需要管理这个平台特有的C、.NET组件，而且需要在其他平台中重用，既不包含C／.NET，也不允许RTTI的非托管C++组件，因此，为了设计一致性，后一种方法似乎更明智。

给定所选的方法，无论是哪种语言，都可以在引用类中嵌套一个引用类的好候选（如果编译器不将嵌套类作为成员处理），则在C++中进行FREST。

关于悬空引用问题，如果程序集中可能不包含引用类，那么可以在引用类中包含引用基类的实例（可能是静态的，也可能是经过特殊处理的），以避免未能引用和/或执行（同样，客户将使用覆盖工具查找）引用基类使用的referer接口。

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

---

egr

希望，该工具对.NET本身进行调整的能力同样适用于自主开发的框架，但仍将允许我们使用内置于合作伙伴基础产品中的.NET CF发行版。谢天谢地，在我们的一些产品中，我们的客户不希望出现的未使用的功能纯粹是我们自己的，而不是.NET本身的一部分。看看吧，不幸的是，它的价格太高了，不能不引起我们首席财务官的激烈争论。也许还有其他更便宜的链接器。我还没有找到它，因为我目前不需要它。祝你好运这不是我的“C++视图”：客户需要一个没有未使用部件的封闭系统。它们可能会运行代码覆盖率，如果攻击者强制引用，则存在可能会被jit的不需要的功能代码，这是一个足以被拒绝的漏洞。还将查看分离和省略程序集