SAConnection threw an exception... Cannot find the language resource file dblgen16.dll

[Former Member]

This is my situation. After installing SA 16 developer in my development machine I can connect to the database without any problems. I just add the reference to iAnywhere.Data.SQLAnywhere.v4.0 in my ASP .Net project (Visual Studio 2012) and everything is fine. Then when it is time to deploy I perform the following steps:

1. Go to the deployment folder in SQL Anywhere 16 folder
2. Create the installer using all the defaults.
3. Move the installer to the target machine (which is Windows Server 2012 R2 running IIS 8.5 and .Net framework 4.)
4. Install the client.
5. Check the environment variables PATH, SQLANY16 (always have to edit/add them manually because the installer is not doing that part)

After deploying the application, each time it tries to connect to the database fails with this (simplified) error message:

System.TypeInitializationException: The type initializer for 'iAnywhere.Data.SQLAnywhere.SAConnection' threw an exception.
at iAnywhere.Data.SQLAnywhere.SAConnection..ctor(String connectionString) 
at edu.southern.image_server.RetrievePersonPicture.WriteContent(Stream stream) 
caused by iAnywhere.Data.SQLAnywhere.SAException: Cannot find the language resource file (dblgen16.dll).
at iAnywhere.Data.SQLAnywhere.SAUnmanagedDll.get_Instance() 
at iAnywhere.Data.SQLAnywhere.SAConnection..cctor()

Then I uninstall the client and install the developer's tool (without the server related stuff) and after it finishes the application just works fine. That to me says that the installer from the deployment tools is missing something, what that could be? I'm clueless at this point, and of course I don't want to install developer tools to each one of my production servers. What am I missing here?

[chris_keating]

The wizard should add the path and set SQLANY16 in the SYSTEM variables and some other registry entries.

Can you confirm the version and build that you are using to generate the install? Can you post or email the {your_install_filename}log generated by the wizard to {first_name}.{last_name}@sap.com.

Can you confirm that the file dblgen16.dll is in the location where you have pointed the path?

Can you also confirm the bitness of the dll. To do so, open the properties for the file (select properties from the popup menu for the file), navigate to the Details tab, and provide the Product Version value. It should be 16.0.0.xxxx (64-bit) based on the server machine assuming that you are compiling as Any CPU.

[Former Member]

• DeploymentWizard.exe is version 16.0.0.1691
• Yes the dblgen16.dll is located where path is pointing to.
• As for the bitness of the dll. I have BIN32 and BIN64 installed and my application is compiled for Any CPU so I'm assuming that it will look for the right dll.

[chris_keating]

The MSI file appears to be correct. With both bitnesses installed, SA should be able to locate the appropriate bitness based on the bitness of the .NET application. Process Explorer (http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx) should be able to provide more insight into why this DLL is not being resolved.

[jeff_albion]

I just add the reference to iAnywhere.Data.SQLAnywhere.v4.0 in my ASP .Net project (Visual Studio 2012) and everything is fine. Then when it is time to deploy I perform the following steps:**

Since this is an ASP.NET deployment, see the discussion in this question (CC'ed below):

---

It looks like you're trying to use the ADO.NET provider from IIS (w3wp.exe) for an ASP.NET application...? Is that correct?

If so, you may want to look at this related StackOverflow question that deals with the same issue (not specific to SQL Anywhere).

C:\\Windows\\System32\\Inetsrv is apparently considered IIS' "current working directory" for DLL references and you can put unmanaged DLLs in there for IIS' purposes.

The first matching DLL with the correct bitness will be the DLL located for this operation. As mentioned in the above StackOverflow thread, you can set the path explicitly in your code, using:

System.Environment.SetEnvironmentVariable("Path", searchPath + ";" + oldPath)

---

The general answer to this problem is discussed in this question and SAP KBA #1984310.

[VolkerBarth]

Confine this similar question: Should deployment wizard update path and set SQLANY16?

As Jeff does explain there, the SA 16 Deployment Wizard currently seems to miss some PATH and registry entries, but you can add that yourself.

[chris_keating]

Thanks for that correction. I was testing some other issues recently and had erroneously used a development build for quickly testing this.

Make sure that if you are manually creating the entries missed by the Wizard to define them as SYSTEM level values for visibility by IIS if configure to use the Local system account.

[VolkerBarth]

and had erroneously used a development build for quickly testing this.

So this is already fixed internally and will be available via EBF in a while?

[jeff_albion]

I'm not sure of the issue that Chris saw in his testing, but CR #755094 is still unresolved internally. (I will still update the other thread as promised, once I hear further).

---

The workaround posted in the other thread should be a good workaround for now to this issue.

You can always check with Orca in the "Environment" table to see that the MSI is generated correctly with the currently missing environment variables. You can also directly edit an MSI in Orca with the values specified in the other thread to have existing MSIs updated with the required environment variables.

[Former Member]

I did modify the master xml file as Jeff suggests on the other question but still same problem. Path and SQLANY16 are now updated/created but the dll is still not found. Uninstalling Deployment and installing Developer selecting only SQLAny32 and SQLAny64 fixes everything, no more errors after that.

[jeff_albion]

Path and SQLANY16 are now updated/created but the dll is still not found.

Are you restarting IIS after the deployment has finished? It won't pick up the new PATH environment variables until after it restarts.

[Former Member]

Yes, I've tried that too. The interesting thing is that after installing developers (instead of deployment) setup and even without restarting IIS the app just works.

[jeff_albion]

The other thing I can think of that might be different is the way between these installations is how you're accessing the provider in your ASP.NET application and how it registers with the system.

Are you using a web.config file with a <connectionStrings> and <add ... providerName="">? If so, you will be going through the Global Assembly Cache (GAC) and the machine.config via the DBProviderFactories class invariant loading mechanism. If you're not using this mechanism, how are you loading the SQL Anywhere assembly?

If you manually run SetupVSPackage /i after the install is finished, what happens?