“扁平化”(简化)C#源的工具

时间:2012-01-10 01:18:39

标签: c# refactoring obfuscation code-conversion

我需要向第三方提供源代码的副本,但鉴于它是一个可以轻松改变用途的漂亮的可扩展框架,我宁愿提供一个较少的OO版本(一个'程序'版本,因为缺少一个更好的术语)允许对值等进行微调,但不能使用当前结构的完全灵活性进行重新实现。

代码使用了通常的东西:类,构造函数等。是否有一种工具或方法可以将其“简化”为仍然是“源”的东西,但只使用普通变量等。

例如,如果我有一个类实例'myclass'在构造函数中初始化this.blah,那么可以用一个名为myclass_blah的变量完成同样的操作,然后以更“扁平”的方式操作。我意识到在这种情况下可能无法实现像多态这样的事情。也许一个混淆器,设置为“超级温和”设置会实现它吗?

由于

3 个答案:

答案 0 :(得分:6)

我使用漂亮的可扩展框架的经验是,大多数商店都有自己漂亮的可扩展框架(通常不止一个),并且不太可能从供应商提供的源代码中窃取它们。如果您有义务提供源代码(由于某些业务关系),那么,至少在我看来,以可维护的形式提供实际源代码是一种道德义务。你如何保护源代码是一个法律问题,我不能提供法律建议,但实际上你应该在你的发布中包含一些许可,并与不会直接窃取你的IP的客户打交道(假设它实际上属于你的你正在开发它的术语。)

答案 1 :(得分:3)

如前所述,如果这是基于合同限制的要求,则不要这样做。简而言之,提供与其实际运行时不同的源版本将成为一种责任,我怀疑它是贵公司应该愿意接受的。证明提供的代码与他们运行的代码匹配很简单。如果您试图避免应用程序使用的库的许可限制(例如GPL),也是如此。

如果不是这样,那么为什么不提供一个只能与内部类型一起使用的可扩展性框架的有限版本,并在应用程序中静态编译任何所需的扩展?这将允许应用程序继续运行它们当前运行的同时保持可维护而不放弃您的神圣框架。我自己从来没有这样做过,但这听起来像是ILMerge可以帮助的。

答案 2 :(得分:1)

如果您不想发表框架 - 请不要。只提供您认为必需的来源。否则,您很可能将来需要支持这两个版本,或者再也不会与这些人(以及他们认识的人)一起工作/互动。

不要忘记,非混淆的.Net程序集具有易于编译形式的IL。使用ILSpy / Reflector读取别人的代码通常比查看源代码更容易。

如果提供代码的原因是某种检查(甚至只是查看代码),你最好有半代码。如果其代码看起来使用C#(http://www.nikhef.nl/~templon/fortran/fortran_style)以FORTRAN样式编写,我会认真考虑丢弃工具。

旁注:我相信“漂亮的可扩展框架”是“未在这里发明”综合症的根源之一 - 我更担心框架上的评论(比如“这段代码是@#@#@因为它不使用YYY模式,间距错误“),而不是重用。