'Application' is ambiguous between declarations in Modules...

The full error is:
My.Application error BC30562: 'Application' is ambiguous between declarations in Modules 'Videstra.My.MyProject, Videstra.My.MyProject, Videstra.My.MyProject, Videstra.My.MyProject'.

I'm at a loss for where all of these modules are located or what to do about this. The result is that all calls to My.Application.Info.DirectoryPath returns a null string on execution, but shows the above error when debugging.

It seems to be identifying 4 modules with the same name, but I don't know where to look for what look to be duplicate declarations...

What I would do is bring up your find box(Control + F), change the file search from current document to entire solution, and search for the keyword application. Then ignore any that you use My.Application, but pay attention to anything like:

Code:

---

Namespace Application

'Or

Class Application

'Or

Structure Application

'Or

Module Application

---

Anything like that will cause an ambiguity and should be renamed to something else.

THanks - unfortunately I found no instances of any of those in the entire solution.

Could you post your designer file? I have a suspicion that it was auto-generated code.

create a new application with the same name and attempt to replicate the issue.

Quote:

---

Originally Posted by dday9

Could you post your designer file? I have a suspicion that it was auto-generated code.

---

Well - I've done some investigation into this and found some interesting things, but still no "good" solution.
I have written several DLLs with custom controls that I use in my application. Each of them has a unique assembly name, but I use the "Videstra" name space for all of them. That seems like something I should be able to do... (right?)
So application A has two or three custom controls as DLLs in a graph that looks like this:

My Main Application VCManager.Exe Namespace: Videstra
Custom Control VCMPanel.DLL Namespace: Videstra
Custom Control EZSMTP.DLL Namespace: Videstra

What it appears to be is that the main application and each of the custom controls represent an instance of My.Application. If I remove those custom controls then the problem disappears.

I add the custom controls by adding a reference to the DLL under My Project>>Properties>>References and then instantiate the control manually (e.g. MyNewControl as new FancyControl).

I can provide the designers as you request but there are designers for the forms and designers for the resources and designers for the settings - is there a particular one that you would like me to post?

I would suspect that it would be in your form designer being that you mentioned that it is custom controls that are causing the issue. But if that's the case then you should explicitly type the namespace prior to the control, ie:

Code:

---

Friend WithEvents MyNewControl As New Videstra.FancyControl

---

Thanks for the suggestion - I was already instantiating the control with Friend. But your suggestion gave me the idea to change the namespace of the main application to something other than Videstra - and this has indeed fixed the problem. I would think that it would not care, but it clearly does... and sets up a conflict between my application and controls...

Des

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

That's a really good "best practices" approach. I will adopt this approach and change my namespaces accordingly. I'm betting this will take care of the issue fully. Thanks for your input!

Des