You can alias types like this: using Foobar = XXX.YYY.XXX.Foobar
This should fix up conflicts If they still exist you can create virtual names: using XFoobar = XXX.YYY.XXX.Foobar private CFoobar ... On 21 April 2010 17:29, Simon Haigh <simon_ha...@pillar.com.au> wrote: > Quick question about namespaces. > > Company policy has been that we have our namespaces as > <CompanyName>.<ApplicationArea>.<whatever>. (e.g. MyCompany.Foobar.API) > > Recently we added a new Application area to our support team and we > built up our namespaces as per our policy. Rightly or wrongly we used > the vendors name as the application area. > > Now we want to use come controls provided by the vendor and they use a > similar namespace naming standard. (e.g. Foobar.Control) > > So when I reference the control on my form I get a compile error on the > line: > > private Foobar.Control myControl; > > . > "Error 1 The type or namespace name 'Control' does not exist in > the namespace 'MyCompany.Foobar' (are you missing an assembly > reference?)" > > So it seems like its looking in the MyCompany.Foobar.* namespace instead > of the Foobar.* namespace. > > Is there a way around this or am I going to have to recode our namespace > names so that they don't include the vendor name. > > Hope this all makes sense. > > Thanks > Simon > > ************************************************************************************************************************ > This email (including all attachments) is confidential, may contain personal > or legally privileged information and is intended solely for the named > addressee. Confidentiality or privilege is not waived or lost because this > email has been sent to you by mistake. If you have received it in error, > please let us know by reply email, delete it from your system and destroy any > copies. > This email is also subject to copyright. No part of it should be reproduced, > adapted or communicated without the written consent of the copyright owner. > Any personal information in this email must be handled in accordance with the > Privacy Act 1988 (Cth). > Emails may be interfered with, may contain computer viruses or other defects > and may not be successfully replicated on other systems. Pillar > Administration makes no representations and gives no warranties in relation > to these matters and does not accept liability for any loss or damage which > may result from this email. > If you have any doubts about the authenticity of an email purportedly sent by > Pillar Administration, please contact us immediately. > ************************************************************************************************************************ > -- regards, Preet, Overlooking the Ocean, Auckland
