【问题标题】:Strategy for developing and testing an SDK that will reside in the GAC开发和测试将驻留在 GAC 中的 SDK 的策略
【发布时间】:2011-03-09 17:26:30
【问题描述】:

我正在开发一个供我们公司内部使用的 SDK。它不会在公司外部部署(以 SDK 形式,它将作为我们产品中包含的运行时部署)。其他开发组将使用此 SDK 开发产品,并将通过 setup 获取 SDK(他们不会从源代码管理中提取源代码或二进制文件)。作为设置的一部分,SDK 程序集将放置在目标机器上,它们也将安装在 GAC 中。部署产品时,SDK 的“运行时”msm 将用于在 GAC 中安装 SDK 的程序集。

因此,每个开发人员都将在他们的机器上安装 SDK。当他们想要添加引用时,他们将浏览到 SDK 的安装位置(或者,如果我们决定注册程序集,则通过添加引用对话框上的 .NET 选项卡获取它)。当他们运行他们正在开发的产品时,程序集将由 GAC 解析。

这一切似乎都很合理。

我的问题是关于我作为 SDK 开发人员的最佳工作方式。我将主要从事 SDK 方面的工作。因此,除了为 SDK 编写代码外,我还将编写测试代码、测试应用程序、示例等。针对“已安装”的 SDK 编写测试是否更好(即从其“已安装”位置引用程序集,确保程序集安装在 GAC 中,以便在测试(等)运行时,它们会像在现实生活中一样从 GAC 解析?)如果我以这种方式工作,那么当我在 SDK 上工作时,如果我进行更改,我需要确保修改后的程序集在 GAC 中。

除了开发 SDK 之外,我还可能为实际的产品功能做出贡献,这些功能反过来可能会利用 SDK 中的功能。同样,我似乎应该针对“已安装”的 SDK 进行工作,以便我使用与其他人相同的版本。

也许我过于复杂了,但我对管理 SDK 上(由我)在本地完成的工作、针对“已部署”程序集 (GAC) 运行/测试以及如何/if 在两者之间转换。我的部分问题是我在从事“大型”项目的应用程序开发方面拥有丰富的经验,而我不必处理这些类型的问题(部署、构建过程等)。也就是说,我一直是任何内部开发的 SDK 的消费者,而不是生产者(或生产者/消费者)。我也是最近才从 C++/COM/VB6 过渡到 .NET 开发。无论如何,我将主要使用 C# 进行开发,并将开发(或贡献于)类库和 WCF 服务。

我确实在 SO 上找到了这个关于在使用 GAC 部署的程序集时测试问题的链接:

Testing code in GAC deployed assemblies

但我不确定它对我有多大帮助。

无论如何,感谢任何人都能够分享的任何提示或想法。

【问题讨论】:

    标签: c# .net deployment sdk gac


    【解决方案1】:

    你把事情复杂化了。从本地应用程序 bin 目录加载程序集与从 GAC 加载程序集在功能上没有区别。对于单元测试,使用最简单和最快的解决方案:只需运行引用 SDK 程序集的测试,这些程序集已由构建过程复制到测试应用的本地 bin 目录中。

    您应该有一个不同的测试步骤来练习加载一个引用您位于 GAC 中的 SDK 的应用程序,以确保您没有任何签名问题,但这更像是一个系统范围的集成测试,应该是在发布之前和任何安装配置更改之后运行。由于搞砸 GAC 安装的可能性相对较小,因此不需要一直对其进行监控,IMO。

    您在开发环境中设置的安装先决条件越少,每个开发人员在新机器上设置所需的时间就越少。保持干净和简单的开发环境有利于一般的开发人员理智,但当您有多个开发人员,每个开发人员都使用多个 VM 进行开发和测试时,这一点尤其重要。

    【讨论】:

    • 感谢您的回答。我确实觉得我可能把事情复杂化了,但这种特殊的工作情况/环境对我来说仍然是新的,所以我仍在努力寻找自己的方式。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-04-05
    • 1970-01-01
    • 2013-01-23
    • 1970-01-01
    相关资源
    最近更新 更多