0

概述

  • 在过去的 3 年里，我们用 C# 构建了一个功能齐全的软件包
  • 我们的软件以这样一种方式构建，它可以处理应用程序所需的大量低级管道，以便我们的开发人员可以专注于他们试图解决的特定问题，而不是所有细节。这显着缩短了开发和发布时间
  • 因此，代码被分解成不同的项目以给我们逻辑分离（例如前端 MVC 应用程序、服务层、核心框架层等）
  • 我们的核心框架项目内置了很多功能（应用程序的主要“胆量”），并且已经精心组织成所有人都熟悉的各种命名空间（例如数据访问、IO、日志记录、邮件等）
  • 当我们最初构建这个时，我们的目标始终是让我们的团队成为目标受众，我们的开发人员对各种新功能进行编码并根据需要添加到框架中。

挑战

  • 现在老板希望能够向我们公司以外的第三方开发人员和团队开放我们的代码库。这些第 3 方人员需要能够直接利用我们的核心库并构建他们自己的模块，这些模块将与我们的服务器一起部署在我们的服务器上。仅仅由于应用程序的性质，我们无法通过 REST 或 SOAP 或类似的方式向它们公开功能来解决问题，它们需要在类似于我们自己的环境中工作，在那里它们可以针对我们的核心库进行开发和编译他们自己的 DLL 用于发布
  • 这在知识产权（我们必须能够保护我们代码的内部运作）、分发、部署、版本控制和测试和发布方面提出了许多担忧和挑战，也许最重要的是我们将如何塑造框架以最好地满足这些要求需要。

你会提供什么建议？你会如何处理这个问题？你希望改变什么样的事情，或者你希望转向什么样的设计方法？我意识到这些问题非常开放，甚至可能含糊不清，但我主要是从可能面临类似挑战的人那里寻找来自您自己背景的任何建议、资源/教程或故事。谢谢！

4

2 回答 2

2

我不确定 MEF 的答案是否真的能解决您的问题。即使使用接口和 MEF 将实现与合同分开，您仍然需要交付实现（我理解您的问题），因此，MEF 不会阻止您交付带有 IP 的程序集。

底线是，如果您需要分发您的实现程序集，这些第 3 方将拥有您的 IP，并具有反编译它们的能力。.NET 无法解决这个问题，最后我检查了一下。您可以使用混淆来使其更加困难，但这不会阻止某人反编译您的实现，只会使其更难阅读和理解。

正如您所指出的，最好的方法是将实现置于 SaaS 类型的边界之后，但这听起来是不可能的。

我要补充的是，我强烈建议开发一个健壮的版本控制模型。这将影响您如何定义接口/API、如何随时间更改它们以及如何对程序集进行版本控制。如果您不小心，并且您没有在程序集中同时使用AssemblyVersion和AssemblyFileVersion处理这个权利，可悲的是）。 阅读这些，因为在我看来它们对 API/组件供应商非常重要。

NDA 和/或许可协议是另一种方式，正如@trailmax 所指出的，如果您认为您的用户会尊重此类协议（个人与公司可能会以不同的方式看待此类协议）。

哦，还要确保您使用强名称签署您的程序集。为此，您可能需要制定保护您的签名密钥的策略。乍一看这似乎很简单，但充分保护您的签名密钥并不像乍看起来那么容易。您通常必须为不同的环境拥有多组密钥，需要将密钥合并到 CI/CD 系统中，并且需要确保对发布密钥的访问受到严格控制。

于 2013-03-18T18:06:26.957 回答
0

正如@HighCore 已经说过的，为您想要公开的所有内容实现接口。将它们放入单独的项目/存储库中，并授予对项目/存储库的只读访问权限。但是你的接口必须有正确的文档记录，否则其他人可能会很痛苦。

这样你的代码对他们来说是不可见的，他们仍然可以处理它。

如果这不起作用，并且您被迫向他们展示您的代码，请让他们签署 NDA。NDA 应该声明您的代码是您的，他们不能以任何方式重新分发它。

我想我的回答和问题一样模糊，但给了你一些想法。

于 2013-03-18T17:50:57.183 回答