jayblaze2
jayblaze2

Reputation: 23

Why do I have to add System.Data.Entity to use System.Data.Objects?

I am still learning about programming as you can probably tell by my question.

How come I have to add System.Data.Entity as a reference to my project to use System.Data.Objects? Does Objects live in namespace System.Data.Objects? Wouldnt it make sense for Objects to live in System.Data.Entity.Objects?

Upvotes: 2

Views: 2169

Answers (4)

Jon Skeet
Jon Skeet

Reputation: 1501033

Namespaces and assemblies are entirely separate concepts. Sometimes - heck, often they will match up, but they certainly don't have to. You don't tend to use the mscorlib namespace, for example :) Likewise most of the System.Linq types are in System.Core.dll. One assembly can contain types in multiple namespaces, and multiple assemblies can contribute to the same namespace.

It's worth keeping the two concepts as distinct in your mind as possible. Fortunately it's easy to find out where a type "lives" in both respects from MSDN.

Upvotes: 3

Brian R. Bondy
Brian R. Bondy

Reputation: 347296

The assembly is called System.Data.Entity which means the DLL System.Data.Entity.dll.

System.Data.Objects is a namespace within that assembly.

A single assembly may contain one or more namespaces possibly all with different names.

Upvotes: 0

SLaks
SLaks

Reputation: 887509

The System.Data.Objects namespace is defined in System.Data.Entity.dll.

Upvotes: 0

Mike Burton
Mike Burton

Reputation: 3020

The .NET namespaces are cross-assembly. This allows the library designers to expand particular namespaces as appropriate without polluting core libraries with non-core functionality. The naming of individual DLLs is unfortunate, but it is not intended to reflect namespace information in the way you're thinking.

In your example, System.Data.Entity is a DLL containing elements from a number of different namespaces. One of these is System.Data.Objects, as you've discovered.

Upvotes: 4

Related Questions