.net failures on 64 bit server

[Former Member]

We have a small number of .Net DLLs that we call from SQLA. They have worked fine for 3 years now, but lately we have had trouble with 2 new installation. I "think" the common denominator is the problems occur on 64 bit Windows servers. - One server was Windows 2008 R2 64 bit. We received errors until the IT folks re-installed Windows and for some reasons our errors disappeared. - Now we have a new installation on Windows Server Standard SP2 64 bit and are encountering errors:

SQL Anywhere Network Server Version 11.0.1.2686
    I. 10/23 19:03:59.    at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams) 
I. 10/23 19:03:59.    at iAnywhere.MarshalToAppDomain.ExecuteMethod(String str, String className, TextWriter textWriter, String methodName, Object[]& args) 
I. 10/23 19:03:59.    at iAnywhere.MarshalToAppDomain.ExecuteMethod(String str, String className, TextWriter textWriter, String methodName, Object[]& args) 
I. 10/23 19:03:59.    at iAnywhere.SAClrClassLoader.Execute(String methodSig) 
I. 10/23 19:03:59. Method 'InterfaceHTTPClient.HttpWSRequest.getMACAddress' not found. 
I. 10/23 19:03:59. if_interface_request: checking MAC address. Procedure 'if_get_mac_address_clr' terminated with unhandled exception 'Method 'InterfaceHTTPClient.HttpWSRequest.getMACAddress' not found.'
I. 10/23 19:03:59. Exception in if_get_memos: Procedure 'if_get_mac_address_clr' terminated with unhandled exception 'Method 'InterfaceHTTPClient.HttpWSRequest.getMACAddress' not found.'
I. 10/23 19:03:59. Exception in event ev_if_get_memos. Message: Procedure 'if_get_mac_address_clr' terminated with unhandled exception 'Method 'InterfaceHTTPClient.HttpWSRequest.getMACAddress' not found.'

Our installations are simple: - we copy the folder of a few DLLs to the server - Add the folder to the PATH

Since I barely know how to spell .Net, I don't know where to start tracking down the problem. Any suggestions would be greatly appreciated.

[MCMartin]

Is the assembly registered in the GAC? Are all needed .net Versions available on the machine?

[Former Member]

I did check to make sure .net 3.5 is installed.

We have never installed assemblies in the GAC. Perhaps due to lack of understanding; my understanding from MSDN is that you only need to register assemblies that will be shared, otherwise just keep them in the app folder (thus we add the PATH).

would this requirement be different on 64bit servers?

[MCMartin]

The requirement is not different on 64bit servers, but assemblies are loaded from the path in which the .exe is which requests the assembly. As this is often not a location of your control it is much easier to place them in the GAC. And if I remeber correctly the GAC also has precedence over local stored assemblies in contrast to the dll loading scheme.

Have a look here (Debugging Assembly Loading Failures http://blogs.msdn.com/b/suzcook/archive/2003/05/29/57120.aspx) this might help you to identify what is missing.

[jeff_albion · Accepted solution]

( From the discussion at: http://sqlanywhere-forum.sap.com/questions/7385#7428 )

In SQL Anywhere 11, the CLR gets launched as 'Any CPU', meaning that it will pick up whichever bitness the operating system is running as. (This issue was solved in SQL Anywhere 12 where bin32\\dbextclr12 is explicitly compiled for 'x86' and bin64\\dbextclr12 is compiled for 'x64').

Our installations are simple: - we copy the folder of a few DLLs to the server - Add the folder to the PATH

I'm guessing some of the DLLs to the server you are copying are the 32-bit SQL Anywhere language DLLs. If you deploy the 64-bit DLLs instead, you may have better luck accessing the .NET assemblies.

[Former Member · Accepted solution]

Thanks Jeff. I wasn't very clear in my comment "we copy the folder of a few DLLs to the server". We do a full proper install of SQL Anywhere. The few DLLs I was referring to are the 6 .NET DLLs that we call from SQLA.

One of my colleagues noticed that the DLL we are having trouble with specifically references a Win32 API (ManagementClass oMClass = new ManagementClass("Win32_NetworkAdapterConfiguration"). Our other DLLs still work fine.

So until I have time to learn to be a .Net programmer, we have just created a workaround to avoid that DLL for now.

As for the 64 bit server that does work, it is a newer Windows Server 2008 R2, so I can only guess that Microsoft may have solved some 32/64 compatibility issues themselves.

[Former Member]

A stab in the dark:

Any change in case you run 32-bit dbsrv11.exe instead of 64-bit dbsrv11.exe?

A .net assembly can be marked for a specific CPU type or "AnyCPU". CorFlags.exe can be used to check or set the assembly's target CPU (http://msdn.microsoft.com/en-us/library/ms164699.aspx).

[Former Member]

we don't have a .Net programmer anymore, so we don't currrently have access to CorFlag.exe. I'll try running the 32 bit server this evening when I can shut the server down.

[Former Member]

I have tried while running with the 32 bit dbsrv; same error. I have found CorFlags.exe and used it to verify the DLL is compiled for "AnyCPU". I have tried registering the DLL with Gacutil.exe and received an error "not a strongly named assembly".

so we are still left with the error and wondering why this all works on the several 32 bit server installations, one 64 bit server, but not this 64 bit server.