Anyone tried using the Sybase.AdoNet2.AseClient from ASP.NET?

[Sumo]

So, has anyone here had 100% success in using the Sybase ADO.NET
driver from ASP.NET applications?

And, by success, I mean:

1. No GAC registration
2. No installation of the SDK on the server
3. XCOPY deployment

I am going to guess that the answer is no.

I have been fighting with this driver for about 5 years now. The fact
that there is an unmanaged DLL (or DLLs) that is required, causes
undue pain in deploying and maintaining ASP.NET applications which are
supposed to be very simple.

I just tried upgrading to the latest version (SDK 15.5 ESD #1
v2.155.1001.0) on my local machine where I use Windows 2008. I had
the previous SDK 15.0 installed and removed it, rebooted it, deleted
any leftover sybdrvad20.dll files left around. No matter what I do,
the driver cannot find sybdrvado20.dll no matter where I put it.

If you understand ASP.NET at all, you will know that by default, it
creates shadow copies of its running assemblies in the temporary
folder for the version of the .NET framework you are using. That
means, Sybase's instructions to just put the dll in the \bin folder is
faulty. This does not work.

So, I tried something else. I tried copying the file to the path
somewhere (C:\WINDOWS\System32 seems like a good place as suggested by
Sybase). This does not work.

At this point, I decided to take matters into my own hands. I
included the sybdrvado20.dll in my application as an embedded
resource. Then, I found/enhanced some code to pull that file out of
its resource and write it to the file system. I took this a step
further, used reflection, and found what the current executing path is
(which happens to be the shadow copy folder) and wrote the file
there. This doesn't work either.

So, I am at a loss as to how to get this to work 100% of the time
without having to do a GAC deployment or copy the files to some
ridiculous place like system32 or somewhere in the path.

Using Reflector, I can see that the driver simply uses DllImport
("sybdrvado20.dll"). So, what the heck is the problem? DllImport
should find it in the shadow copy folder first, but it should also
find it when I have it somewhere in the path, too. It seems that this
ONLY worked when I had the SDK installed.

Now, a Sybase PLEA: PLEASE make it a priority to write a fully managed
version of this driver. Heck, take the darn Mono driver that was
written a few years ago to support TDS 5, fix its bugs, and re-release
it as open source. Aside from some bugs, it works. Bad part is that
the bugs are show stoppers for us, so we're relegated to using your
driver instead.

Finally, Sybase, can you please publish publicly some documentation as
to what files EXACTLY are needed to use this driver under both .NET
2.0 and .NET 1.1? You include so many files with zero documentation
that we developers are wasting hours debugging.

[Sumo]

So, I believe I have fixed this once and for all. Sybase: Please
document this somewhere so that other people stop having so much pain
with this driver and ASP.NET.

First, for this driver to work, you don't just need sybdrvado20.dll,
you need its other dependencies, too, which may or may not be in a
searchable path. They are all included in the provider:

msvcr80.dll
sybcsi_certicom_fips26.dll
sybcsi_core26.dll
sbgse2.dll

I found this out thanks to Dependency Walker.

So, I fixed this, while also allowing shadow copy to be on by making
sybdrvado20.dll and all of its required dlls as embedded resources.
Then, at runtime, I have the application write these files to the
folder where Sybase.AdoNet2.AseClient.dll is written to (you'll need
to use reflection to figure it out). Once I did this, it started to
work (after, of course, I also fixed the 12.5.x codepage error by
adding Charset='iso_1' to the connection string).

This should also solve the deployment time problem of files being
locked as once the app is restarted, it should use a new shadow copy
folder.

[Sumo]

Sybase,

If you are listening, please properly embed your unmanaged
dependencies following this documentation:

http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.dllimportattribute.dllimportattribute.aspx

Basically, you can include the unmanaged dlls as resources and
directly reference them with DllImport inside the assemebly where they
are embedded rather than requiring that the files be included
separately somewhere in the system. It would save us developers some
deployment pain and would give you more time to finish creating a 100%
managed provider.

[GG]

Sybase has recently opened a case for a managed ado provider
but it is low priority. May be if other people request it,
they may increase the priority.

> Thanks a lot for your information.
>
> As I am going to use this drive as well, your information
> would be useful for me.
>
> "Sumo" <msum...@gmail.com> wrote in message
> news:a960812c-5b95-4883...@k23g2000yqa.goog
> > legroups.com... So, I believe I have fixed this once and

[Paul Vero [Sybase]]

Yes - we need customers to open a case to TSE and request this Please -
then we attach the request to an open CR we have requesting a fully managed
Provider. This way we in support can indicate to the product folks how
many customers are asking for this and we can push this request.

Thank you,

-Paul

<GG> wrote in message news:4b426017.7e9...@sybase.com...

[iamk...@gmail.com]

We had this issue and found that installing the .dll's in the environment path works pretty well. We initially installed them \System32\Inetsrv. In our installation we create a folder with the .dll's and add the folder to the path.

The genesis for this solution is here:
http://stackoverflow.com/questions/344608/unmanaged-dlls-fail-to-load-on-asp-net-server