CODEWITHSUNDEEP
.netvb.net
Denis
Denis

Reputation: 12087

How does VB.NET know which variable to set if the variable name appears in 2 modules in 2 dlls

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?

Upvotes: 2

Views: 286

Answers (3)

Mark Hurd
Mark Hurd

Reputation: 10931

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.

Upvotes: 0

jColeson
jColeson

Reputation: 971

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.

Upvotes: 2

Dave Doknjas
Dave Doknjas

Reputation: 6542

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.

Upvotes: 5

Related Questions