Q:

How does MS Entity Framework map from the conceptual model to CLR types?

Given an Entity Data Model (EDMX) with "Code Generation Strategy" set to "None", how does EF determine which CLR types to map the conceptual model to? 
I think I read somewhere that it just probes the assembly for types that match the conceptual model, but that was in reference to a CTP edition of EF. Is this still the case?
Can I control this process somehow?
In particular, I am in a scenario where I am moving a substantial codebase from using Linq2SQL to using POCO with EF 4.0. Thus, I have the Linq2SQL classes as well as my POCO classes, for now residing in the same assembly, but in different namespaces. I'm trying to have a smooth migration from L2S to EF so I would like to have the two frameworks run in parallel for a while. However, I get a runtime-error saying

The mapping of CLR type to EDM type is
  ambiguous because multiple CLR types 
  match the EDM type 'SomeType'.
  Previously found CLR type 
  'SomeNamespace.SomeType', newly found
  CLR type 'SomeNamespace.POCO.SomeType'

where SomeNamespace is the namespace of the L2S entities. This error makes sense if EF is just probing for all types matching the conceptual model. Can I confine EF to only probe the SomeNamespace.POCO namespace? Or should I put my POCO objects in another assembly? Or should I take a third approach?
Thank you.

A:

Notice this comment from the ADO.NET team blog:

Jeff 25 Feb 2010 9:10 AM @Derek
This is intentional. You can put your
  POCO classes in whatever namespace
  you'd like. The Entity Framework's by
  convention mechanism for detecting
  which properties on the entity match
  the properties of entities in your
  model does not use Namespace. What
  matters is that the type name (without
  namespace) matches the EntityType name
  in your model (edmx/csdl file).
One area to watch out for is if you
  have multiple types with the same name
  but in different namespaces. Because
  we don't account for namespace, we
  detect that we've found multiple types
  and we throw an exception.
Jeff

See this article:
link text

