SQL Server DLLs

Question

I'm upgrading to 64 bits a Windows application that manages medical and research equipment and I'm soliciting some high-level just-get-started assistance...

My stumbling block is .NET references to SQL Server DLLs, in particular, two "mysteries" (described below). I've posted a similar query on two Microsoft forums but have not heard anything. Come on SQL Server Wizards! I need your help!

Details:

Target Environments are 64 bit Windows 7 and later systems. While 64 bit OS is a requisite, there's not a snowball's chance of any upgrades to Windows 10. "Windows 7 shall remain Windows 7, Windows 8.1 shall remain" ... you get the idea.
MSVS 2010 (ultimate) C# ...may not use 2012, 2013, 2015 ... similar constraints to those for the OS...
Must be x64 only build ...no Win32, x86, AnyCPU or Mixed Platforms ... well, not quite true, but, for this question, go with the x64-only restriction...

Just to keep things simple (not), the application is a SQL Server client in a replication constellation. That means that the client may have a publish/subscribe relationship with one or more, remote SQL Servers. The original application (32 bit) worked with SQL Server 2008R2. The 64 bit application is to work with 64 bit SQL Server 2014. SQL Server 2016 is not an option as it does not install under Windows 7.

I have a 64 bit Windows 7 development system which has been cleansed of any SQL Server code and then has had SQL Server 2014 Enterprise installed. Yes, this clobbers MSVS 2010, which requires SQL Server Compact 3.5 for IntelliSense. For this question, please disregard that annoyance.

First Mystery:

I did a census of C# usings:

using Microsoft.SqlServer.Management.Common;
using Microsoft.SqlServer.Replication;

...and the original set of (SQL Server 2008R2) references:

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

I noticed that some of the references target DLLs in Windows' GAC; for example,

%WinDir%\assembly\GAC_MSIL\Microsoft.SqlServer.Replication.BusinessLogicSupport\-someGUID-.dll

I think I understand the targeting of the GAC: since SQL Server 2014 will be a pre-installation requirement, rather than providing the DLLs in some form of redistribution element (as would be the case with many applications), they are expected to be resident because of the presence of a running, SQL Server instance.

However, some of the references target DLLs in the SQL Server SDKs; for example:

%ProgramFiles(x86)%\Microsoft SQL Server\120\SDK\Assemblies\Microsoft.SqlServer.Rmo.dll

(this is an x86 DLL ... not good) ...and there is unlikely to be any such SDK on the deployment machines.

...and some target local copies in the build tree.

This I do not understand. I hope I can just reference GAC DLLs, retargeting any references to the SDK (as mentioned, not likely to be present on the target machines) and avoid entirely source tree copies of DLLs. Can anybody explain why the varied sources? Use small words suitable for my limited intellect.

Second Mystery:

Even after installing SQL Server 2014 Enterprise and its related Server Replication Management Pack, I cannot find x64 counterparts for some of the 32 bit DLLs. Am I missing some additional pack? Maybe some of these references were applied during earlier times just "for luck" (no real correspondence to either Management.Common and/or Replication), are not even needed and can be ignored?

Thanks!

One concrete problem is a bit difficult to state. "How to Migrate a 32 bit SQL Server 2014 Application to 64 bits When SQL Server 2014 Seems to Have 32 bit Versus 64 bit Conflicts" is, unfortunately the most accurate statement. I have received a query from Microsoft and am pursuing that avenue. I'll post a concluding note once I have some details. — We B Martians, Aug 01 '16 at 14:46
While I haven't wrapped this issue up, I have made progress. Rather than posting a duplicate entry here, note that I have posted a lot of maybe useful solutions and work-arounds but also some explicit questions at social.msdn.microsoft.com: [link](https://social.msdn.microsoft.com/Forums/sqlserver/en-US/9fe9961b-4381-47ff-81ea-d317c6142a00/migration-from-2008r2-to-2014-issues-with-replication?forum=sqlservermigration#db4903d9-1859-44f4-af15-ae4cfdba03f3) Best! — We B Martians, Aug 11 '16 at 23:31
So that the site will show that this question has been answered... https://social.msdn.microsoft.com/Forums/sqlserver/en-US/9fe9961b-4381-47ff-81ea-d317c6142a00/migration-from-2008r2-to-2014-issues-with-replication?forum=sqlservermigration#db4903d9-1859-44f4-af15-ae4cfdba03f3 — We B Martians, Jul 16 '18 at 11:19

score 0 · Answer 1 · answered Jun 12 '23 at 10:45

I have developed several packets (mostly on nuget) which are using SQL Server dlls, I believe so far I can explain what is happening in high level like you mentioned in the Question.

Most Microsoft SQL Server's dlls are under x86 folder or under GAC_32 or under GAC_MSIL, the reason is that those dlls are used for querying or designing, for example in my library EzApi2022 (https://www.nuget.org/packages/EzApi2022) which is used to export a dtsx package from C# all are 32bit.

That does not mean it will execute on 32bit, because if in my case the exported dtsx file (xml definition) be deployed on SQL Server 64bit, it will execute under 64bit.

I a not sure what dlls are you using and for what reason but I do not see any problem using those dlls you find (32bit) if you are not going to hit any limitation doing simple straightforward things. (In my case I hit the C# object limitation of 1GB which comes though the SQL Server dll, so to overcome this I had to improve the code and change the logic).

At the end, maybe replication dlls and the dlls I used for design of dtsx have the same strategy. I suppose you are about to create publication / subscription using a programming language, so there is not need to have 64 bit for those kind of operations. Replication performance is about of SQL Server Version running inside the engine which will be 64bit.

Hope I provided some clarity.

SQL Server DLLs

1 Answers1