2

So I spent 2 hours trying to figure out this weird error in VB.NET. Finally figured it out but I can't figure out why it sometimes would work and sometimes won't. I had 2 DLLs both of which had a MODULE called _Main.vb which had a variable called "MDIParentForm". If I import both DLLs as references for a third assembly and do:

MDIParentForm = Something

Which "MDIParentForm" am I setting? The one in the first Assembly? in the second Assembly? Seemed like if I ran it in "Debug" mode it would set one Assembly and in "Release" it would set the other assembly and break my code... I'm a C#/Java programmer by nature so don't really get how "Module" works in VB.NET and since no namespace or classname is required to call its members how the heck do you know what member you are setting?

Denis
  • 11,796
  • 16
  • 88
  • 150

3 Answers3

5

VB has more than one 'feature' that can lead to coding horrors such as this one. The solution is to qualify the module member with the module name.

The fact that VB allows you to use unqualified module members doesn't mean that this is a good idea.

Dave Doknjas
  • 6,394
  • 1
  • 15
  • 28
  • oh, I so agree but this code was there before me and I just got stuck in the nightmare but it is interesting how it would decide to resolve this. Seems like this should be an error plain and simple. – Denis Sep 10 '12 at 21:09
  • 2
    I can think of at least a dozen weird things that VB allows that should not be allowed. – Dave Doknjas Sep 10 '12 at 21:11
  • VB6 was even worse. I just found out last week that VB6 allows you to override internal VB Functions. Yikes... thats a mess waiting to happen. – logixologist Jun 29 '13 at 06:31
2

This ability is mostly a legacy thing from VB 6.0, which was a procedural language not an object orientated language.

Microsoft made some poor decisions (in my humble opinion) in the VB.NET specification in order to make it easier to convert VB 6.0 programs to .NET. Having converted many VB 6.0 programs, I can say, without hesitation, that they failed at the goal of making conversions easier.

That being said I do find the feature useful for utility like functions and singleton objects.

For more details and rants

To answer your actual question...

If the identifier is defined in the same assembly, it will use that one. If it's defined in a single referenced assembly, it will use that one. In the case where it is defined by multiple assemblies, it should be requiring you to fully qualify it with the assembly name. At least that is my understanding.

Make sure Option Strict and Option Explicit are turned on at the project level. Also try importing only one of the assembly's namespaces in the top of your vb file. Doing so should get you more consistent results at the very least.

tl;dr

Just fully qualify every reference to the identifier with the dll and namespace name.

Community
  • 1
  • 1
jColeson
  • 951
  • 1
  • 14
  • 24
0

I have attempted to replicate your scenario, and yet (with vbc corresponding to VS2008) I always receive a compile error:

'MDIParentForm' is ambiguous between declarations in Modules 'Test.M' and 'Test.M'.

and this was independent of Option Strict or Option Explicit On or Off.

And just to clarify, you said "since no namespace or classname is required to call its members": This is not true, you exactly need to ensure the Namespace is available; then the content of the Module is.

Mark Hurd
  • 10,665
  • 10
  • 68
  • 101