The type or namespace name 'OracleClient' does not exist in the namespace 'System.Data'

jaredk picture jaredk · Aug 31, 2012 · Viewed 29.1k times · Source

When trying to run my code, I receive the following error:

CS0234: The type or namespace name 'OracleClient' does not exist in the namespace 'System.Data' (are you missing an assembly reference?)

I have included references to System.Data.dll and System.Data.OracleClient.dll, but I am still getting this error.

The error is being caused by the line using System.Data.OracleClient in my namespace declaration.

Answer

Jon Hanna picture Jon Hanna · Aug 31, 2012

The using System.Data.OracleClient directive means that that namespace should be considered when trying to determine what non-full names mean.

Adding a reference, means you add a reference to a given assembly, in this case System.Data.OracleClient.dll. From VisualStudio, SharpDevelop or MonoDevelop you will see a references folder in the project explorer view. Right click and "Add Reference" (VisualStudio and SharpDevelop) or "Edit References" (MonoDevelop), and add in System.Data.OracleClient.dll

If using nant you'll need to edit your nant script.

Assemblies and namespaces overlap, but aren't quite the same. The reference means you can use e.g. System.Data.OracleClient.OracleDataReader because the project now knows what assembly the code for that lives in. The using directive means you need only type OracleDataReader. There tends to be a heavy match between assemblies and namespaces because that makes life easier for everyone, but there are both times when an assembly has classes from more than one namespace, and when a namespace is split over more than one assembly. A classic example is that mscorlib has a lot of classes from System, System.Collections, System.IO etc. that you couldn't really hope to build a .NET project without (including some that .NET uses itself), while System.dll has a bunch more from exactly the same namespaces that you could feasibly get by without using (but you still will 99% of the time).

Unless you're writing an absolutely massive library though, with thousands of classes covering overlapping use-cases, your own assemblies should work with a single namespace - or at most a single one with some other namespaces within that one, like JaredksGreatCode having JaredksGreatCode.UserInterface within it - per single DLL.