Where are the 64-bit MANAGED Dlls in SQL Anywhere 12.0.1?

[Former Member]

We are currently running SQL Anywhere 12.0.1, EBF 3895 in our application. We have been running it 32-bit only. We now want to run it 64-bit on 64-bit machines.

I reinstalled SQL Anywhere on my machine & installed it for 32 & 64 bit environments. When I look in the C:\\Program Files\\SQL Anywhere 12\\Assembly\\V4 folder, however, there are only the same managed DLLs we have in our application now.

Our installer currently installs the 32-bit version of SA. I don't know what the plan is, but if we install the 64-bit SA executables, do we need 64-bit managed DLLs to go along with that? If so, are there any changes we need to make to our projects to get them to work with the 64-bit SA install? Are there any changes we have to make in app.config?

If we don't need 64-bit managed DLLs, how do we get our program to work with the 64-bit install? Again, are there any changes we have to make in app.config?

[chris_keating · Accepted solution]

These managed files can be used for both bitness. By default, .NET managed code is bitness agnostic meaning that it will run aither as x86, x64 or Itanium depending on the chip and the operating system bitness. Note that SQL Anywhere currently only supports x86 and x64.

This behaviour is controlled by the "Any CPU" Platform option in the configuration manager. You can change this to x32 to force a 32-bit only build, x64 to force a 64-bit only build, or Itanium to force an Itanium only build. In generally, you would leave this at its default value unless you had unmanaged code that was bitness/chipset specific.

[Former Member · Accepted solution]

Thanks, that's what I thought, given that there was only one set of DLLs.

I seem to recall a problem I had some time ago where I had build my program with Any CPU and a DLL that was embedded in one of the SA DLLs had the wrong bitness. The managed code was running as 64-bit, but the server running was 32-bit only. What I think you're saying is the reason this happened is because the managed code's bitness didn't match the bitness of the server. If everything is the same bitness, there's no problem. Correct?

[chris_keating · Accepted solution]

I recall an issue with unpacking the unmanaged DLL but I cannot recall the details - it has been fixed for some time.

There should be no problems provided that the managed and unmanaged code are the same bitness,

[Breck_Carter · Accepted solution]

In addition to what Chris said...

Some of the files listed below appear in the V4 folder, and others appear in both the bin32 and bin64 folders.

.NET client deployment

SQL Anywhere provider for .NET Framework 4.0 The SQL Anywhere installation places the Windows assemblies for the .NET Framework version 4.0 in the Assembly\\V4 subdirectory of your SQL Anywhere installation directory. The other files are placed in the operating-system binaries directory of your SQL Anywhere installation directory (for example, bin32 or bin64). The following files are required.

iAnywhere.Data.SQLAnywhere.v4.0.dll

policy.12.0.iAnywhere.Data.SQLAnywhere.v4.0.dll

dblg[LL]12.dll

dbicu12.dll

dbicudt12.dll

dbcon12.dll

SSDLToSA12.tt

[Former Member · Accepted solution]

Now that I've got everything building & running properly, I've been able to confirm that building & running the application as 32-bit connects to a 32-bit or 64-bit server without error, and the same is true if you build & run it as 64-bit. We didn't have to make any code or configuration changes. We're happy! 😉