.net VS2005“配置”；“撤退”；动态链接库

我正在尝试向.NET2.0应用程序添加SQL2008支持。然而，我的独特之处在于，一些用户仍将使用SQL2005，我不想要求他们安装SQL2008客户端组件

SQL2008所需的实际DLL集与SQL2005不同。代码可以保持不变

Botton行，我需要在VS2005（或手动编辑程序集文件）中说：

如果用户有DLL_1 v2、DLL_2 v2和DLL_3 v2，请使用它们。如果没有，请使用DLL_1 v1和DLL_2 v1

---

我将研究使用反射来加载DLL，这似乎是我除了需要SQL 2008客户端组件之外的唯一选择

至于重新分发DLL，我确实读了许可证。这里有几个适用于我们的可疑术语（例如，对于托管软件）。另外，这是一个更复杂的问题，因为我们的客户数据非常敏感，所以他们需要经过广泛的批准流程，才能安装任何东西，例如我们包含的DLL

谢谢你的帮助

---

谢谢你的想法！然而，我们还没有完全做到这一点

否，用户没有选择要安装的DB版本。其目的是允许SQL2005和/或SQL2008，即使在相同的安装中也是如此。例如，我们有一个管理应用程序，允许用户跨不同的SQL Server管理数据库实例

我意识到我们可以添加一个对话框来选择是否需要SQL2008支持。然而，这将进一步扩展我们的测试矩阵，这正是我们试图避免的

我相信我确实需要直接参考DLL。我在数据库方面做的工作远远不止是连接和查询

我需要的DLL是：

• Microsoft.SqlServer.ConnectionInfo
• Microsoft.SqlServer.Management.Sdk.Sfc
• Microsoft.SqlServer.Smo
• Microsoft.SqlServer.SmoExtended
• Microsoft.SqlServer.SqlEnum

---

还有其他想法吗？

您可以在代码中更改表适配器的连接字符串，因此有必要为SQL2008编写全新的DLL吗？

如果您只是在进行基本数据访问，您不必担心，任何一个本机客户端都可以正常工作，您可以让框架为您连接到它。如果指定SQL客户机，.Net将使用它可以使用的任何一个。您正在使用SMO对象吗？在这种情况下，可能存在一些依赖性问题。

您根本不必直接引用任何DLL。如果您使用System.Data.SqlClient连接到您的DBs，那么.Net将知道如何与这两个DBs通信。如果您没有使用System.Data.SqlClient与服务器通信，那么下一个问题是您是否可以切换到该名称空间进行DB通信

---

这可能有点超出了您想要做的范围，但是您可以创建一个服务层抽象，其中每个人都连接到服务层，服务层处理与DB服务器的路由和通信，您可以通过SOAP或.Net远程处理与服务层通信。我已经开始将我的所有应用程序切换到这种方法，因为它允许我将业务逻辑和db抽象集中在一个受控位置，并在本地计算机上处理演示文稿。

用户是否选择要安装的db版本？（我假设有某种安装过程）。能否根据选定的数据库版本交换安装时bin文件夹中的dll文件？

反射将允许您在运行时动态加载所需的dll集。因此，您可以检测可用的内容，然后加载它

---

唯一的缺点是使用反射会使您的工作变得更加困难和耗时。

您可以使用服务容器并在配置文件中连接依赖项。这可能需要将依赖于任意一组程序集的代码分离为单独的类和程序集

两个类库，一个用于2005年，一个用于2008年，都包含一组实现一组公共接口的类。然后，应用程序将只向服务容器请求实现一个公共接口的对象，应用程序配置文件将指示将使用哪个实现

当然，这种配置也可以在应用程序启动时用代码完成

这种方法还允许您不仅仅使用一组不同的dll。如果某些事情需要在2005年与2008年有所不同，您可以在类库中实现这些差异，而应用程序也不会更明智