Oracle Data Access blues: 64 bit ODAC

MS Outlook --> Power point Presentation in attachment--> quick preview --> Mouse cursor dissappears

Recently, I was facing this nagging issue pretty often.

A brief description of the problem:

When you try to do a quick preview of a Powerpoint presentation that came to you by mail, what happens quite often is that post the presentation, the mouse cursor dissappears.

There are many suggested ways to tide over this problem.

I have discovered a easy way out of it. In case this happens, just click on the ppt once more for another quick preview, and voila the cursor will reappear!!! 

Oracle.DataAccess.dll version mismatch...

In a recent project I was faced with this problem:
I had compiled a local asp.net mvc project pointed to my installed version of the Oracle.ataaccess.dll (from the GAC). Instead of a complete project deployment, I was supposed to just replace the main project dll in the server.

Upon deployment, I found that the version of the Oracle.Dataaccess.dll was not the same and i was getting a "Version Mismatch error", whenever there was a call from the site to the Oracle DB. The Ora Client version in my dev box was 12.1.1.0.
To add to it, the environments of the Dev and the Web server were also different. My local dev box was a 32bit Win 7 whereas the webserver was a 64bit Win Server 2008 R2.

So the first challenge was to know what is the installed version of the Oraclient in Server.
I could not locate the Oracle Client in the usual place on the server, i.e., C://Oraclient/Products/.
1. So I opened the Environment Variables of the server and from the Path Variable found the path to the Oraclient.
From there I got the Oraclient version.
2.  I opened the GAC of the machine to confirm the version
3. I downloaded the exsiting dll of the mvc project and dissembled it (using ILSpy) to see the referenced Oracle version.

I found that the used version on the server was 11.2.3.0
----------------------
Now that I know of the 2 versions, the next challenge was to fix the mismatch of the versions.
The first thing which came to my mind was to uninstall the local version, download and install the one on the server, recompile and the replace the dll.
But that was a cumbersome process, and I couldn't find the exact oraclient version on the net too.
So, I investigated aa little more... From the experience of a previous project, i knew that in the web.config we can instrument the assembly which we want to be loaded.

Then I found this website with the steps: it was not an exact same scenario, but quite close.
(http://tiredblogger.wordpress.com/2008/11/06/getting-oracledataaccess-working-on-x64/)

taking a cue from the website I added the following section to my web.config

<dependentAssembly>
       <assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89b483f429c47342"/>
       <bindingRedirect oldVersion="0.0.0.0-4.121.1.0" newVersion="4.112.3.0"/>
</dependentAssembly>

and voila, after the deployment of the new dll, it was working fine....

ohh and BTW, I got the public key token of the installed oraclient version from the dissembled dll.

What NOT to do in ASP.NET

Excerpted from Scott Hanselman's blog. 

A must read for all web programmers...

(Original source: http://www.hanselman.com/blog/ChecklistWhatNOTToDoInASPNET.aspx)

----------------------------------------------------------------------------------------

• Standards Compliance
  • Control Adapters - Control adapters were a good idea in .NET 2, but it's best to use solid adaptive CSS and HTML techniques today.
  • Style Properties on Controls - Set CSS classes yourself, don't use inline styles.
  • Page and Control Callbacks - Page Callbacks pre-date standard AJAX techniques, so today, stick with SignalR, Web API, and JavaScript.
  • Browser Capability Detection - Check for features, not for browsers whenever possible.
• Security
  • Request Validation - While Request Validation is useful, it's not focused and it doesn't know exactly what you app is doing. Be smart and validate inputs with the full knowledge of what your app is trying to accomplish. Don't trust user input.
  • Cookieless Forms Authentication and Session - Don't pass anything auth related in the query string. Cookieless auth will never be secure. Don't do it.
  • EnableViewStateMac - This should never be false. Ever.
  • Medium Trust - Medium trust isn't a security boundary you should count on. Put apps in separate app pools.
  •  - Don't disable security patches with appSettings.
  • UrlPathEncode - This doesn't do what you think it does. Use UrlEncode. This method was very specific, poorly named, and is now totally obsolete.
• Reliability and Performance
  • PreSendRequestHeaders and PreSendRequestContext - Leave these alone making managed modules. These can be used with native modules, but not IHttpModules.
  • Asynchronous Page Events with Web Forms - Use Page.RegisterAsyncTask instead.
  • Fire-and-Forget Work - Avoid using ThreadPool.QueueUserWorkItem as your app pool could disappear at any time. Move this work outside or use WebBackgrounder if you must.
  • Request Entity Body - Stay out of Request.Form and Request.InputStream before your handler's execute event. It may not be ready to go.
  • Response.Redirect and Response.End - Be conscious of Thread.Aborts that will happen when you redirect.
  • EnableViewState and ViewStateMode - There's no need to hate on ViewState. Turn it off everywhere, then turn it on only for the individual controls that need it.
  • SqlMembershipProvider - Consider using ASP.NET User Providers, or better yet, the new ASP.NET Identity system.
  • Long Running Requests (>110 seconds) - ASP.NET isn't meant to handle long running requests that are a minute (or two) long. Use WebSockets or SignalR for connected clients, and use asynchronous I/O operations.