System.Data.Services.Internal is rather visible

So, if you've been going through the System.Data.Services.Internal namespace, you might have noticed that the types are rather visible. What's up with that?

Well, the types are used to ask LINQ provider to do $expand projections as necessary. Projecting is rather interesting, because the providers will need to look at these types and instantiate them at some point or another. We wanted LINQ provider writer to be able to write code that didn't require requesting any privilege elevations to get at these types and instantiate them, call methods on them and so on and so forth.

Typically the projection can be done using LINQ to Objects and by making the types visible, 'it just works' from any privilege level - a LINQ implementation could generate IL referencing these types, use reflection over visible types, or whatever strategy they choose to implement.

And now you know.

Comments

• Anonymous
  August 19, 2008
  Then why not put them in a better namespace than 'internal'? I'm surprised we let this through the namespace approval..

• Anonymous
  August 20, 2008
  Well, these types are not meant to be referenced externally in most cases - thus the moniker. Typically processing code such as LINQ providers will reference them at run-time, analyze them using reflection and possibly get & set properties using reflection and/or IL, so being visible eases requirements on the them, but direct usage won't happen while developing data services per se. Also, while the data service will produce queries that reference these types, they are accessed by the rest of the system through the System.Data.Services.IExpandedResult, so even custom LINQ providers that are Data Services-aware are unlikely to have a direct reference. All said, I wish we had a better organization solution for this, but a .Internal suffix had precedents and solved our concerns without interfering with API usage.