ADO unpacking dlls into %TEMP% proble,

[Former Member]

When ADO unpacks its dlls into %TEMP%, it can cause a race condition when 2 programs are running at the same time.

It can also cause issues on shared machines, where %TEMP% is more restricted.

Why does it grant "FullControl" of the dlls to other users - from a security perspective it raises concerns.

Could it be made optional to not unpack any dlls  and use an installation directory instead if we already have one.

We can then be in full control over whats happening and stop the race conditions.

[dawn_kim]

Hi Mike,

I know why they granted full control. This was related to a couple of development items. Starting with SDK 15.7 ESD#4. We included all the ddls in the Sybase.AdoNet#.AseClient.dll. So people didn't have to specify the platform 32 or 64 bit they were building on it was all included. When in use it needed to expand, they originally tried to the user directory but there were to many permission limitations on that directory. So they went with the temp directory. We found we had to expand the permissions on our files to use the temp directory. I know in the past their was issues with multiple open connections in each directory. I haven't heard of anything recent.
Are both running applications use the same pool? Or when you have second instance running do you create another pool?

Thanks,
Dawn Kim

[Former Member]

Thanks for the information - I can understand the advantage of including the dll's and unpacking them for most users but what happens if 2 apps running as different users have 32 and 64 apps sharing a machine and a %TEMP%.

However, we need more control over it and it would be useful not to unpack it at all if we don't want to.

[dawn_kim]

Hi Mike,

What if you build it a specific way and put all the necessary files in the bin of the build?

https://wiki.scn.sap.com/wiki/x/oghiGQ

Thanks,
Dawn Kim

[Former Member]

I'm not sure I understand the wiki page but will pass onto someone with more experience of ADO.

Are you suggesting we build our own Assembly file ?

But as far as I can tell the 8 libraries which are unpacked and loaded are hard-coded and you can't stop the CreateDirectory of the %TEMP%/<assemblyname>....<32/64>...<version>

so not sure what you're suggesting.

[ryan_hansen]

Hi,

I believe the idea is to add the DLLs in the application folder to prevent conflicts.

This way the application doesn't have to create a temp directory and prevents this contention.

Example for framework 4.0:

Sybase.AdoNet4.AseClient.dll

sybdrvado20.dll

sybcsi_certicom_fips26.dll

sybcsi_core26.dll

sybcsi_openssl26.dll

sybcsi_profiler26.dll

sbgse2.dll

Regards,

Ryan

[Former Member]

Adding the dll's to the application folder and not have the temp directory created would be great.

But won't the ADO driver always try and create the folder and unpack the assembly ?

How do we turn off the directory creating and unpacking ?

[ryan_hansen]

Hi,

You should be able to remove the assembly and policy file from the windows machine.

Then add all of these files into the application folder.

This would be a similar setup to run multiple ado.net versions on one windows machine.

Attached are a few examples.

Note: rename the attachment to .zip.

Regards,

Ryan

MultipleAdoNetVersions.txt.zip

[former_member89972]

Ryan

What is attachment manifest ? (i.e. contents or list of files ?)

No matter how I rename  the downloaded file and I can see only binary files !!

Avinash

[ryan_hansen]

There are 2 files in a zip.

One .docx the other .rtf

I just created a mdocs folder so you can download them there:

https://mdocs.sap.com/mcm/public/v1/open?shr=lZBHyC8kBp3DgGC6lhoi8M-anHSdjWXtd7i056ZXyZI

It is open until Dec.

Regards,

Ryan

[Former Member]

I can't see how this will stop the unpacking and loading of the libraries ?

Removing the libs from the assembly will cause an error when the libraries are attempted to be loaded.