|
I was attempting to deploy an application to one of our test servers and ran into the issue that dblgen12.dll was missing. After adding this to the bin folder of my application I was dismayed to find out that this did not solve my issue. Following a little bit of digging I was able to gleam that dblgen12.dll was expected to be in the C:Windows folder or some where in the %Path% variable. While this does make my application work it does create other issues. Every application on the server would need to be using the same version of the dataprovider. This isn't always possible and requires extra effort when it comes to deployment, something that we'd like to avoid. Has anyone been able to come up with any workarounds for this? EDIT - using V 12.0.1.39244 |
|
You might find that the application executable directory is a good option. It is not recommended to use the Windows directory structure as its intent is for system level components rather than application binaries. Please review also the file search algorithm used by SA components for a complete set of locations used by SA to locate required files. See http://dcx.sybase.com/index.html#1201/en/dbadmin/da-install-s-5107108.html. Note that there are other deployment files that may be required by the .NET provider. See http://dcx.sybase.com/index.html#1201/en/dbprogramming/deploying-adonet-deploy.html for details. 1
So I understand what you are saying... and it is the case for the IAnywhere.Data.SQLAnywhere dll, however it doesn't appear to be the case with it's dependency dblgen12.dll which coincidentally appears to be the only DLL that actually matters. I've tested things with the following scenarios: All the files mentioned in the documentation in the bin folder (I'm running under IIS) All the files in the Windows directory The actual iAnywhere.Data.SQLAnywhere.dll in the bin folder The actual iAnywhere.Data.SQLAnywhere.dll and dblgen12.dll in the bin folder The actual iAnywhere.Data.SQLAnywhere.dll in the bin folder and dblgen12.dll in the Windows folder The only combination of things that seems to work at all is the last one.
(27 Aug '13, 14:22)
elindalyne
I am not sure why adding the DLL to the same location as the BIN folder of your deployed site is not resolving this. I tested that and it worked for me. Perhaps Process Monitor can shed light on what is happening?
(27 Aug '13, 16:04)
Chris Keating
I have actually run ProcessMonitor at the behest of one of the Sybase techs... It doesn't appear to look in the bin folder at all. Every directory other than the bin folder sure, but not the bin folder.
(28 Aug '13, 09:17)
elindalyne
Replies hidden
The file path algorithm will be looking for 'bin32' or 'bin64' - for your .NET project, are you running it as 'AnyCPU', 'x86' or 'x64'? You will need to deploy the binaries that match the current bitness of the .NET environment you are running - 'AnyCPU' will be 32-bit on 32-bit systems and 64-bit on 64-bit systems. 'x86' will be 32-bit on 32-bit and 64-bit systems, and 'x64' can only run in 64-bit environments. Your screenshot indicates that we're checking 'C:\Program Files\SQL Anywhere 11\bin32\' and 'C:\Program Files\SQL Anywhere 11\bin64\', but can't find the files. Where is SQL Anywhere installed on this system?
(28 Aug '13, 10:15)
Jeff Albion
Comment Text Removed
Jeff - The entire point of doing this is to not need to install SQL Anywhere and to be able to use the same version of the data provider in our development, testing and production environments. If you are limited to only having one version of the dblgen12.dll on the system this would mean we'd have to update every single developer machine, test server and production server if anyone wants to update their data provider.
(28 Aug '13, 10:47)
elindalyne
1
Understood - I was confused as to the fact that you are deploying SQL Anywhere 12 components, but we're finding a SQL Anywhere 11 path already present (it's already defined on the 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).
I'm not sure I follow this part exactly - if you're intending to update the build of the provider, yes, you will need to distribute all of the ADO.NET provider files, including the managed and unmanaged components...? 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)
(29 Aug '13, 12:13)
Jeff Albion
|
|
Workaround: If you have the luxury of using a shell script to start it (myprogram.cmd) you can start your app as the 2nd line and modify your path in the first to point to your app bin file. set path=c:program filesmyapp;%path% |
