No more System.Data.OracleClient

from Artinsoft's blog: http://blogs.artinsoft.net/Mrojas/archive/2009/08/07/No-more-SystemDataOracleClient.aspx


 Microsoft announced that they won’t support the System.Data.OracleClient anymore :(

The message says that it will still be available in .NET 4.0 but “deprecated” and that it wont impact existing applicatoions.

So what are my options?

Well you have to go to a third party. Not now but eventually.

Oracle Data Provider for .NET (ODP.NET) (Oracle states that ODP.NET is Free)

DataDirect ADO.NET Provider for Oracle

dotConnect for Oracle

Migration to ODP.NET

Installation

Microsoft OracleClient to ODP.NET Application Migration: Code Migration

Oracle provide general instructions. In summary you need to:

1. Add the references to Oracle.DataAccess
2. Change namespaces: System.Data.OracleClient by  Oracle.DataAccess.Client; and maybe add “using Oracle.DataAccess.Types”
3. Update the connection String (most attributes are the same). Change Integrated Security by  "User Id=/", change “Server” attribute to “Data Source” and remove Unicode
4. The following is anoying but you have to add after all OracleCommands something like OracleCommand1.BindByName = true;

Deployment

• Oracle Universal Installer (either in normal installation or Silent Install)
• XCopy (I like this :) ) just remember to download the ODAC xcopy version

Microsoft Lost the Backwards Compatibility Religion

Excerpt from Joel Spoelsky:

"

Microsoft Lost the Backwards Compatibility Religion

Inside Microsoft, the MSDN Magazine Camp has won the battle.

The first big win was making Visual Basic.NET not backwards-compatible with VB 6.0. This was literally the first time in living memory that when you bought an upgrade to a Microsoft product, your old data (i.e. the code you had written in VB6) could not be imported perfectly and silently. It was the first time a Microsoft upgrade did not respect the work that users did using the previous version of a product.

And the sky didn't seem to fall, not inside Microsoft. VB6 developers were up in arms, but they were disappearing anyway, because most of them were corporate developers who were migrating to web development anyway. The real long term damage was hidden.

With this major victory under their belts, the MSDN Magazine Camp took over. Suddenly it was OK to change things. IIS 6.0 came out with a different threading model that broke some old applications. I was shocked to discover that our customers with Windows Server 2003 were having trouble running FogBugz. Then .NET 1.1 was not perfectly backwards compatible with 1.0. And now that the cat was out of the bag, the OS team got into the spirit and decided that instead of adding features to the Windows API, they were going to completely replace it. Instead of Win32, we are told, we should now start getting ready forWinFX: the next generation Windows API. All different. Based on .NET with managed code. XAML. Avalon. "

http://www.joelonsoftware.com/articles/APIWar.html

Windows uses Unicode, and specifically UTF-16 encoding

Windows natively supports Unicode strings for UI elements, file names, and so forth. Unicode is the preferred character encoding, because it supports all character sets and languages. Windows represents Unicode characters using UTF-16 encoding, in which each character is encoded as a 16-bit value. UTF-16 characters are called widecharacters, to distinguish them from 8-bit ANSI characters. 

Unicode and ANSI Functions

When Microsoft introduced Unicode support to Windows, it eased the transition by providing two parallel sets of APIs, one for ANSI strings and the other for Unicode strings. For example, there are two functions to set the text of a window's title bar:

• SetWindowTextA takes an ANSI string.
• SetWindowTextW takes a Unicode string.

Internally, the ANSI version translates the string to Unicode. 

New applications should always call the Unicode versions. Many world languages require Unicode. If you use ANSI strings, it will be impossible to localize your application. The ANSI versions are also less efficient, because the operating system must convert the ANSI strings to Unicode at run time.

Size of a pointer

Pointer Precision Types

The following data types are always the size of a pointer — that is, 32 bits wide in 32-bit applications, and 64 bits wide in 64-bit applications. The size is determined at compile time. When a 32-bit application runs on 64-bit Windows, these data types are still 4 bytes wide. (A 64-bit application cannot run on 32-bit Windows, so the reverse situation does not occur.)

• DWORD_PTR
• INT_PTR
• LONG_PTR
• ULONG_PTR
• UINT_PTR

Reliving the Evolution of Visual Studio...

On a 64-bit Win7 laptop:
Year 1998. Starting with Visual Studio 6 (aka Visual Basic 6). Installed successfully.
Year 2002 Visual Studio .NET.  Refused to install on 64-bit machine.
Installed on my old laptop, a 32-bit XP Pro.
Flaky when tried installing from disc, so had to copy files locally to a folder named DVD1 (per some online advice).  Gives option to install MSDN Help.
Year 2003. Visual Studio .NET 2003.  Installed on 64-bit laptop.  MSDN NOT installed with main app!  Rather, it came with separate discs (3 CD's) to install separately.
Visio, though marketed as the distinguishing feature of this Enterprise Architect edition, was provided as a standalone disc and standalone installation.