2008-12-30 62 views
3

我想将SQL2008支持添加到.NET 2.0应用程序。但是,我的独特之处在于某些用户仍然会使用SQL2005,并且我不想要求他们安装SQL2008客户端组件。VS2005配置“回退”DLL

我需要SQL2008的实际DLL集不同于SQL2005。代码可以保持不变。

波顿线,我需要在VS2005的方式(或手动编辑组件文件)说:

如果用户有DLL_1 V2,DLL_2 v2和DLL_3 V2选用它们。如果不是,请使用DLL_1 v1和DLL_2 v1。


我会研究使用反射来加载DLL,这听起来像是除了需要SQL 2008客户端组件之外的唯一选项。

至于重新分配DLL,我没有读取许可证。那里有一些可疑的术语适用于我们(例如托管软件)。另外,这是一个更复杂的问题,因为我们的客户数据非常敏感,所以他们会通过广泛的审批流程来允许安装任何东西,比如我们包含的DLL。

感谢您的帮助!


感谢您的想法!然而,我们仍然不是那里...

  1. 不,用户不选择他们安装到哪个数据库版本。目的是允许SQL2005和/或SQL2008,即使在相同的安装。例如,我们有一个管理应用程序允许用户跨不同的SQL服务器管理数据库实例。

  2. 我意识到我们可以添加一个对话框来选择是否需要SQL2008支持。但是,这会更多地扩展我们的测试矩阵,这正是我们试图避免的。

  3. 我相信我确实需要直接引用DLL。我对数据库做了很多工作,而不仅仅是连接和查询。

我需要的DLL是:

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

任何其他想法,想法?

回答

0

您可以在代码中更改表格适配器的连接字符串,那么是否需要为SQL2008编写全新的dll?

0

如果您只是在进行基本的数据访问,您不需要担心,本地客户端应该可以正常工作,并且可以让框架为您准备好。如果你指定了SQL客户端,。网络将使用它可以得到的任何一个。你在使用SMO对象吗?在这种情况下,可能存在一些依赖性问题。

0

你不应该直接引用任何DLL。如果您使用System.Data.SqlClient连接到您的数据库,那么.Net将知道如何与他们交谈。如果您没有使用System.Data.SqlClient与您的服务器进行通信,那么下一个问题就会变成您的数据库通信的名称空间。

这可能稍微超出了您所期望的范围,但您可以创建一个服务层抽象,其中每个人都连接到服务层,服务层处理路由和与数据库服务器的通信,以及您可以通过SOAP或.Net Remoting与服务层进行通信。我已经开始将所有应用程序切换到此方法,因为它允许我将业务逻辑和数据库抽象集中在一个受控位置,并在本地计算机上处​​理演示文稿。

0

用户是否选择要安装的数据库版本? (我假设有某种安装过程)。你能否根据所选的数据库版本在安装的bin文件夹中交换dll文件?

1

反射将允许您在运行时动态加载您想要的DLL集。所以你可以检测到什么可用并加载它。

唯一的缺点是使用Reflection可能会让您的工作更加困难和耗时。

0

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

即,两个类库,一个用于2005年,另一个用于2008年,它们都包含一组实现一组通用接口的类。然后,应用程序会向服务容器询问实现其中一个通用接口的对象,并且应用程序配置文件将指示将使用哪个实现。

该配置当然也可以在应用程序启动时以代码完成。

这种方法还可以让你做的不仅仅是使用一组不同的dll。如果2005年的某些事情需要与2008年的不同,那么你可以在你的类库中实现这些差异,并且应用程序不会更聪明。