开发和测试将驻留在 GAC 中的 SDK 的策略
我正在开发一个供我们公司内部使用的 SDK。它不会在公司外部部署（以 SDK 形式，它将作为我们产品中包含的运行时部署）。其他开发小组将使用此 SDK 来开发产品，并通过安装获取 SDK（他们不会从源代码管理中提取源代码或二进制文件）。作为设置的一部分，SDK 程序集将放置在目标计算机上，并且还将安装在 GAC 中。部署产品时，SDK 的“运行时”msm 将用于在 GAC 中安装 SDK 的程序集。
因此，每个开发人员都会在他们的计算机上安装 SDK。当他们想要添加引用时，他们将浏览到 SDK 的安装位置（或者如果我们决定注册程序集，则通过“添加引用”对话框上的 .NET 选项卡获取它）。当他们运行正在开发的产品时，程序集将由 GAC 解决。
这一切看起来都很合理。
我的问题是关于我作为 SDK 开发人员的最佳工作方式。我将主要致力于 SDK 的工作。因此，除了为 SDK 编写代码之外，我还将编写测试代码、测试应用程序、示例等。针对“已安装”的 SDK 编写测试是否更好（即从“已安装”位置引用程序集，确保程序集安装在 GAC 中，以便当测试（等）运行时，它们会像在现实生活中一样从 GAC 解析？）如果我以这种方式工作，那么当我在 SDK 上工作时，如果我进行更改后，我需要确保修改后的程序集位于 GAC 中。
除了开发 SDK 之外，我还可能为实际的产品功能做出贡献，而这些功能又可能会利用 SDK 中的功能。同样，我似乎应该针对“已安装”的 SDK 进行工作，以便我使用与其他人相同的版本。
也许我把这个问题过于复杂化了，但我对管理在 SDK 上本地完成的工作（由我）、针对“部署的”程序集（GAC）运行/测试以及如何/如果执行的整个问题感到有点困惑。两者之间的过渡。我的部分问题是，我在“大型”项目的应用程序开发方面拥有丰富的经验，在这些项目中我不必处理此类问题（部署、构建过程等）。也就是说，我一直是任何内部开发的 SDK 的消费者，而不是生产者（或生产者/消费者）。我最近才从 C++/COM/VB6 过渡到 .NET 开发。就其价值而言，我将主要使用 C# 进行开发，并将开发（或贡献）类库和 WCF 服务。
我确实从这里找到了关于使用 GAC 部署的程序集时的测试问题的链接：
但我不确定它对我有多大帮助。
无论如何，感谢任何人能够分享的任何提示或想法。
I am developing an SDK for internal use at our company. It will not be deployed (in SDK form, it will deploy as a runtime included with our products) outside of the company. Other development groups will use this SDK to develop products and will get the SDK via setup (they will not pull source or binaries from source control). As part of the setup, the SDK assemblies will be put on the target machine and they will also be installed in the GAC. When a product is deployed, the SDK's "runtime" msm will be used to install the SDK's assemblies in the GAC.
So, each developer will install the SDK on their machine. When they want to add a reference, they will browse to the install location of the SDK (or get it via the .NET tab on the Add References dialog if we decide to register the assemblies). When they run the product they are developing, the assemblies will be resolved from the GAC.
That all seems pretty reasonable.
My question is about the best way for me, as the SDK developer, to work. I will primarily be working on the SDK. So, in addition to writing code for the SDK, I will be writing test code, test applications, samples, etc. Is it better to write the tests against the "installed" SDK (i.e. reference the assemblies from their "installed" location, make sure that the assemblies are installed in the GAC so that when the tests (etc) run they are resolving from the GAC just like they will in real life?) If I work this way, then as I work on the SDK, if I make a change, I will need to make sure that the modified assembly is in the GAC.
In addition to working on the SDK, I may also contribute to actual product features which might, in turn, utilize functionality in the SDK. Again, it seems that I should do my work against the "installed" SDK so that I am using the same version as everyone else.
Maybe I am overcomplicating this, but I feel a little confused over the whole issue of managing the work being done (by me) locally on the SDK, running/testing against the "as deployed" assemblies (GAC), and how/if to transition between the two. Part of my problem is that I have a good amount of experience in application development working on "big" projects where I have not had to deal with these kinds of issues (deployment, build process, etc). That is, I have always been a consumer of any internally developed SDKs, not a producer (or producer/consumer). I have also only recently transitioned from C++/COM/VB6 to .NET development. For what it's worth, I will be developing primarily in C# and will be developing (or contributing to) class libaries and WCF services.
I did find this link from here at SO about testing issues when working with GAC deployed assemblies:
Testing code in GAC deployed assemblies
But I'm not sure that it helped me that much.
Anyway, thanks for any tips or ideas that anyone is able to share.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你把事情搞得太复杂了。从本地应用程序 bin 目录加载程序集与从 GAC 加载程序集之间没有功能差异。对于单元测试，请采用最简单、最快的解决方案：只需运行引用由构建过程复制到测试应用程序的本地 bin 目录中的 SDK 程序集的测试即可。
您应该有一个不同的测试步骤来练习加载引用驻留在 GAC 中的 SDK 的应用程序，以确保您没有任何签名问题，但这更多的是应该在发布之前运行的系统范围集成测试以及在任何安装配置更改之后。由于搞砸 GAC 安装的可能性相对较小，因此不需要一直对其进行监控，IMO。
您在开发环境中放置的安装先决条件越少，每个开发人员在新计算机上进行设置所需的时间就越少。保持干净、简单的开发环境有利于一般开发的理智，但当您有多个开发人员，每个开发人员都使用多个虚拟机进行开发和测试时，这一点尤其重要。
You're overcomplicating matters. There is no functional difference between loading assemblies from the local app bin directory vs loading from the GAC. For unit testing, go with the simplest and fastest solution: just run the tests referencing the SDK assemblies that were copied into the test app's local bin directory by the build process.
You should have a different testing step that exercises loading an application that references your SDKs that reside in the GAC to make sure you don't have any signature issues, but this is more of a system-wide integration test that should be run before release and after any install configuration changes. Since the chances of screwing up your GAC installation are relatively small, it doesn't need to be monitored all the time, IMO.
The less install prerequisites you place on the dev environment, the less time it will take for each dev to get set up on a new machine. Keeping a clean and simple dev environment is good for general dev sanity, but it's particularly important when you have multiple devs who each work with multiple VMs for development and testing.