1

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

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

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

谢谢

4

3 回答 3

6

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

于 2012-01-10T01:40:13.923 回答
3

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

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

于 2012-01-10T02:08:08.800 回答
1

如果您不想给出框架 - 只是不要。仅提供您认为需要的来源。否则很可能您将来需要同时支持这两个版本,或者永远不再与这些人(以及他们认识的人)工作/互动。

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

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

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

于 2012-01-10T03:23:42.220 回答