For someone simple like me, Microsoft’s announcement regarding the sunset of System.Data.OracleClient is sobering news.

While it seems to fit into the company’s recent activities regarding monopoly abuse claims, it is a harsh turn against loyal users for a couple of reasons:

1. A deprecation means, from now on, I’m doing the wrong thing. Maybe I was doing the wrong thing from the start.
2. AFAIK it is the first time, Microsoft abandons an entire chunk of the System.* namespace, where, as far as I were to believe, the most stable interfaces had been homed. A deprecated interface stack for a third-party software is only a broken window for more things to be cut in the future.
3. I’m left with little if any choice regarding stability, quality, consistency, compliance and completeness. Due to the insufficient weight of other vendors, most people will be pushed to Oracle's ADO.NET implementation, the creators of which may or may not choose to support any or all guidelines, interfaces and new services Microsoft conceives in the ADO.NET space, e.g. LINQ or ADO.NET Entities, or may choose to abandon all .NET activities in favor of Java at any time.
4. Due to the countless intricacies, idiosyncrasies and outright wrong individual choices within ODP.NET, not all code can be simply switched over, even (or in particular) when Writing Provider Independent Code in ADO.NET. Since ODP.NET is more tightly integrated with the entire Oracle database stack, differences between database and client versions, patch sets and critical patch updates will become more apparent to the application and more system configurations need to be considered for testing, even if there is an additional layer in between, such as an ORM.
5. ODP.NET or any other third-party provider create an additional deployment requirement, which may conflict with other applications on the same machine in the Global Assembly Cache, in registry settings or arcane areas such as environment variables, and needs more testing and considerations for compatibility.
6. New levels of service and support have to be negotiated for development and runtime, which very likely will be associated with a cost increase, due to plain fees or hours spent on forums and hotlines.
7. The decision affects up-level components, such as ORMs or the Oracle Data Processing Extension for Microsoft SQL Server Reporting Services, for which an extensive number of dependent components has been created that need to be reviewed for compatibility. In the case of SSRS, this decision may affect countless report templates sitting in every imaginable file or content management system.

Obviously, I’m exaggerating.

The pragmatic developer is barely holding it’s laughing that I was using Microsoft’s API in the first place. Everything will be manageable and will Just Work. The implementation from Oracle will be alright and more than sufficient for the insanely simple stuff that was possible with the anyway limited OracleClient, so support will not be needed.

And I should be so happy I have more choices now.