>>Hi Viv,
>>
>>> Snip ***
>>>>I also find another issue that you are mention above. For instance if I do an import of:
>>>>Import MyName.MyProjectA
>>>>Import MyName.MyProjectB
>>>>
>>>>And then both of those projects have a class named Enums it becomes ambiguous when I try to reference it in code. I am apparently not allowed to use the full qualified name such as MyName.MyProjectA.Enums.ErrorLevel = since the Import is there. How do I use an alias in the import? Would that get around this?
>>>

>>>Imports EnumsA = MyName.MyProjectA.Enums
>>>Imports EnumsB = MyName.MyProjectB.Enums
>>>'Then refer as:
>>>EnumsA.ErrorLevel
>>>EnumsB.xxx
>>>

>>>Update: I also don't understand why you have any problem using a fully qualified namespace - that should *always* be available (assuming the project has a reference in the first place)
>>>
>>
>>If I add this I get an error on the line
>>
>>Imports MyName.MyProjectA
>>
>>' Causes an error with the first part underlined
>>errorLevel = MyName.MyProjectA.Enums.ErrorLevel.Informational
>>' No error if I remove the part which is imported
>>errorLevel = Enums.ErrorLevel.Informational
>
>They are not additions - they are replacements.
>Regards,
>Viv

It took me a minute to figure out what you were saying. I think you are referring to my comment of "If I add this..." What I should have said was if I type this. I was trying (not well) to say that if I use the fully qualified name when the Import statement is there it gives me an error. If I take out the part that is already Imported, the error is gone.

I can use the fully qualified name so long as I don't include that in the Import statement. I like to use the Import so I don't have to type the fully qualified name everywhere. But when there is one item that causes ambiguity, I was trying to get around it. It looks like I can use your suggestion above with alias.
Thanks a bunch
Tim