Installing Oracle Client on Windows Server 2008 R2 x64

4 Replies

i had previously installed Oracle client 10g on win 2003 machine to connect to my Oracle db from my .NET app.

this time i wanted to do the same from my Win Server 2008 R2 x64 machine…
for 64 bit machines Oracle has released a 11g 64 bit client which you can get from here:
http://www.oracle.com/technetwork/database/enterprise-edition/downloads/112010-win64soft-094461.html
(win64_11gR2_client.zip).

Run the installation and select the first item (Oracle instance client):

Continue the installation…it will finish in no time.

However, after installation there was no tnsnames.ora and sqlnet.ora files…and there was no Network and Admin folders. In all previous installations these were the folders/files i deal with to set my settings and service names.

What i did next was wierd but worked! i manually created folder Network and inside it created folder Admin…the full path was:
C:\app\username\product\11.2.0\client_1\Network\Admin
And i created the tnsnames.ora and sqlnet.ora inside the above path.
That did the trick.

Before that…

If you are going to invoke Oracle client from a .NET application like me, you will get an error that says:
“Attempt to load Oracle client libraries threw BadImageFormatException. This problem will occur when running in 64 bit mode with the 32 bit Oracle client components installed.”
if your application process is targetting 32-bit.

if you are using a console application, go to project properties –> advanced compilation options and change the target cpu to x64.
From IIS 7 make sure that the setting for the application pool accessing Oracle has “Enable 32 bit applications” set to false.

PS: i read that its an IIS 7 best practice to keep 32-bit processes (pools) working on x64 machines. so the above step might incur performance overhead. my next attempt will be to install Oracle client 32-bit on my x64 machine and see if that works…

WF 4.0 WorkflowServiceHost Custom Tracking

2 Replies

In previous two-part post (here and here) I showed how to add persistence to a workflow hosted via the WorkflowServiceHost. In this post I will do some modifications on the same example to add tracking support. Now since I am a good guy and would like to make your lives easier, I will repost the full code here instead of pointing out only the differences. Let’s roll…
Continue reading →

Web Service First Call Delay – SSL Handshake

1 Reply

i faced this issue recently and hope it helps someone…so here we go:

a service provider gave me a XML Webservice to consume. this service was SSL secured and they gave us the certificate to install. However, they did not give us the CA…lets move on.

i created a .net console app to test the web service and of course i had to write the code to ignore the certificate warning since again i did not have the CA. now do not judge me just yet 🙂 instantly i mailed the web service owner asking for the CA; but it took some time…

so meanwhile, my console app worked just fine. now i went to my main ASP.NET application and used the same code to invoke the web service…and there was a big problem: the first call took forever (more like 30 seconds really), then the subsequent calls were fast until my application is restarted!
now since the console application worked just fine (first call was fast) but the problem was only in the ASP.NET application i moved my attention immediately to the serialzation issue.

i read alot about how the serializer dll might take time to load the first time and thus the first call was slow. Now although this does not really explain why the problem occured only when calling the web service from my IIS hosted web site; however, i still used the SGen tool to pre-generate the serializer assembly in the form of [myproxyassemblyname].XmlSerializers.dll and put it inside my bin folder but without any result…still the first call was too slow.

Note: instead of using the SGen tool you can use the compile options from VS and turn on the generate serialzer assembly option which will create the serialzer dll for you…

now out of no where, the service provider sent my the CA. i installed it in the trusted root certificate authorities folder, removed the warning-ignoring code and boom the first call was fast and the problem was solved!
thinking about it, the SSL handshake on the first call was taking a lot of time to find a problem in the CA and generating a warning.

i have to admit though, it was a by chance. because till this moment i do not know why the console app did not complain about the SSL handshake (or to be more accurate, the SSL handshake did not take much time) while when from IIS the SSL handshake took about 30 seconds…the first logical explanation – although do not quote me on this – is that the IIS worker process was much slower than the .NET managed assembly (console app) in dealing with the SSL handshake issues…

anyway, i can live with this for now 🙂