我正在将一个管理医疗和研究设备的Windows应用程序升级到64位,我正在寻求一些高级别的入门帮助...
我的绊脚石是.NET对SQL Server DLL的引用,特别是两个“谜团”(如下所述)。我在两个微软论坛上发布了类似的查询,但没有听到任何消息。来吧,SQL Server奇才!我需要你的帮助!
详细内容:
- 目标环境是64位Windows 7及更高版本的系统。虽然64位操作系统是必要的,但没有雪球的机会升级到Windows 10。“Windows 7应保留Windows 7,Windows 8.1应保留”...你懂的
- MSVS 2010(终极版)C#...可能不会使用2012、2013、2015...类似于操作系统的限制...
- 必须是x64版本,没有Win32,x86,AnyCPU或混合平台。好吧,不完全正确,但是,对于这个问题,使用仅限x64的限制。
为了使事情变得简单(而不是),应用程序是复制集群中的SQL Server客户端。这意味着客户端可以与一个或多个远程SQL服务器具有发布/订阅关系。原始应用程序(32位)与SQL Server 2008 R2一起工作。64位应用程序将与64位SQL Server 2014一起工作。SQL Server 2016不是一个选项,因为它不安装在Windows 7下。
我有一个64位Windows 7开发系统,它已经清理了任何SQL Server代码,然后安装了SQL Server 2014 Enterprise。是的,这将严重打击MSVS 2010,MSVS 2010需要SQL Server Compact 3.5 for IntelliSense。对于这个问题,请忽略这个烦恼。
第一个谜团:
我做了一个C#使用的普查:
using Microsoft.SqlServer.Management.Common;
using Microsoft.SqlServer.Replication;
...和原始的(SQL Server 2008 R2)引用集:
Microsoft.SqlServer.ConnectionInfo
Microsoft.SqlServer.Management.Sdk.Sfc
Microsoft.SqlServer.Replication
Microsoft.SqlServer.Replication.BusinessLogicSupport
Microsoft.SqlServer.Rmo
Microsoft.SqlServer.Smo
Microsoft.SqlServer.SmoExtended
Microsoft.SqlServer.SqlEnum
我注意到一些引用是针对Windows的GAC中的DLL的;例如,
%WinDir%\assembly\GAC_MSIL\Microsoft.SqlServer.Replication.BusinessLogicSupport\-someGUID-.dll
我想我理解GAC的定位:由于SQL Server 2014将是安装前的要求,而不是以某种形式的重新分发元素提供DLL(许多应用程序都会出现这种情况),因此由于存在正在运行的SQL Server示例,因此预计它们将驻留。
但是,有些引用以SQL Server SDK中的DLL为目标;例如:
%ProgramFiles(x86)%\Microsoft SQL Server\120\SDK\Assemblies\Microsoft.SqlServer.Rmo.dll
(this是一个x86 DLL...不好)...而且部署机器上不太可能有任何这样的SDK。
...以及构建树中的一些目标本地副本。
我不明白。我希望我可以只引用GAC DLL,将任何引用重定向到SDK(如前所述,不太可能出现在目标机器上),并完全避免DLL的源树副本。谁能解释一下为什么有不同的来源?使用适合我有限智力的小词语。
第二个谜团:
即使在安装SQL Server 2014 Enterprise及其相关的Server Replication Management Pack之后,我也无法找到一些32位DLL的x64对应项。我是否错过了一些额外的包?也许这些参考文献中的一些在早期只是为了“运气”(没有真实的的对应关系管理。通用和/或复制),甚至不需要,可以忽略?
谢谢!
1条答案
按热度按时间3htmauhk1#
我已经开发了几个数据包(大部分是在nuget上),这是使用SQL Server dll,我相信到目前为止,我可以解释发生了什么,就像你提到的问题。
大多数Microsoft SQL Server的dll都在x86文件夹下或GAC_32下或GAC_MSIL下,原因是这些dll用于查询或设计,例如在我的库EzApi 2022(https://www.nuget.org/packages/EzApi2022)中,用于从C#导出dtsx包,所有都是32位的。
这并不意味着它将在32位上执行,因为在我的例子中,如果导出的dtsx文件(xml定义)部署在SQL Server 64位上,它将在64位下执行。
我不知道你在用什么样的dll,也不知道是什么原因,但是如果你不想在做简单直接的事情时遇到任何限制的话,我不认为使用你找到的那些dll(32位)有任何问题。(在我的例子中,我遇到了1GB的C#对象限制,这是通过SQL Server dll来实现的,所以为了克服这个问题,我必须改进代码并更改逻辑)。
最后,也许复制dll和我用于dtsx设计的dll具有相同的策略。我假设你要使用编程语言创建发布/订阅,所以不需要64位来进行这些操作。复制性能大约是运行在64位引擎内的SQL Server版本。
我希望我提供了一些清晰。