It doesn't care, nor should it... it sounds like there's something in one of the namespaces of the custom controls that was in direct conflict with something in the main application. That's why here, we manage the namespaces with a specific construct: {company}.{custom or app}.{client (maybe, depends on what we're working on)}.{function}.{SubAssembly} ... what we end up with is something like this:
For base product components: TechGnomeCo.AppFx.Revenue.Catalog
For custom components: TechGnomeCo.CustomFx.Revenue.Catalog ... our UI components are in a UIModel instead of Catalog... client-side components are in Client...

This means that if the product guys create an object of "RevenueDetails" ... it will not conflict with one I might create. It also means I can inherit it and extend it and use it with out the two causing any conflicts.

I suspect you had two classes of the same name in one (or more) of your controls and in the main app... and since it wasn't fully qualified, it tried to make a best guess, but since both used the same namespace, which normally is perfectly fine, it still couldn't resolve which one you meant because the root namespace for both were Videstra. Changing the namespace is the solution, but if it had been me, the controls would have been given a root namespace of Videstra.Controls ... and your application given the root namespace Videstra.{simple app name} ... that way if there are any class naming conflicts, it should be easier to resolve that conflict by adding the FQN.

-tg