VB.Net Release Mode: Reference to a non-shared member requires an object reference

[theryan722]

Hello, there are no errors in my project when in debug mode. When I switch it to release mode, I get a lot of "Reference to a non-shared member requires an object reference" errors.

My project has a main form (the form that is the startup form in the settings) and a few other forms. I make calls from the other forms to the main form, for example from Form2:

frmMain.Text = "TEST"

So I tried creating a class, and doing:

dim testshared as frmMain = frmMain

and then doing

SharedClass.testshared.Text = "TEST"

Yet then it gives me other errors. How do I do this without creating a new instance of the form? It is the startup form, so it seems ridiculous that I would have to have it load, then create a new instance of it, and then manage the reference to that instance.

Any help on solving this would be greatly appreciated.

[Shaggy Hiker]

Well, as to whether or not it is ridiculous, that's a larger philosophical debate. However, to get at the actual problem: How did you decide that is the cause of the problem? It seems unlikely to be the issue, to me, partly for reasons you allude to, but I assume there is a reason why you focused on those references.

frmMain IS a specific instance, it's just the default instance. Default instances were added in 2005 and have been causing confusion ever since, but the confusion is always on the part of the coder, not on the part of the compiler. That's why I find it hard to believe that the issue is with those references. Effectively, the compiler is quietly adding a line like this:

Public frmMain As New frmMain

That isn't really what it is doing, as that would be inefficient. More accurately, when you first make use of frmMain (which in your case is on startup), it is creating an instance of the form that happens to have the same name as the class type. This means that you have a variable frmMain, which is of type frmMain. In your code, when you write frmMain.Text, you are using the variable frmMain not the type frmMain, and the compiler will get this right.

However, you are right that the problem is something like that. Unfortunately, I'm at a bit of a loss to think of a scenario that would work in debug and not in release. Is there only one project in this solution, or are there multiple projects?

[Shaggy Hiker]

By the way, this:

dim testshared as frmMain = frmMain

probably didn't do quite what you expected. Since forms (like all classes) are reference types, the variable frmMain really holds just the address of the actual object, so all you really did was create a variable of type frmMain (which will hold the address of a frmMain object), and copy the address of the frmMain object into it. If this worked, then you wouldn't be getting the exception in the first place, because if frmMain is an instance of frmMain, as it SHOULD be, then there wouldn't be any complaint about not having an instance.

[theryan722]

By the way, this:

dim testshared as frmMain = frmMain

probably didn't do quite what you expected. Since forms (like all classes) are reference types, the variable frmMain really holds just the address of the actual object, so all you really did was create a variable of type frmMain (which will hold the address of a frmMain object), and copy the address of the frmMain object into it. If this worked, then you wouldn't be getting the exception in the first place, because if frmMain is an instance of frmMain, as it SHOULD be, then there wouldn't be any complaint about not having an instance.

I am aware of that. I did it as an attempt to solve the reference error. How do I go about solving this?

[Shaggy Hiker]

Are you sure that frmMain is causing the problem?

[theryan722]

Are you sure that frmMain is causing the problem?

It's anytime I call frmMain from another form or class.

[Shaggy Hiker]

So, you reference things like your example, and wherever you do that you get an exception, but only in the release version. Is that right?

Your example is setting a property of a class that frmMain is derived from, since .Text is a property of Form (or Control, or some other base class). Is this true of EVERY place where you are getting the exception?

The first thing I would try would be to create my own method on frmMain, something like this:

Public Sub SetText(newText As String)
 Me.Text = newText
End Sub

and call that method. It would be pretty interesting if that worked where frmMain.Text did not. It would be replacing your use of a base class property with a derived class method. I would only do this as a test, because it really shouldn't work, but if it did, it would be diagnostic.

[theryan722]

So, you reference things like your example, and wherever you do that you get an exception, but only in the release version. Is that right?

Your example is setting a property of a class that frmMain is derived from, since .Text is a property of Form (or Control, or some other base class). Is this true of EVERY place where you are getting the exception?

The first thing I would try would be to create my own method on frmMain, something like this:

Public Sub SetText(newText As String)
 Me.Text = newText
End Sub

and call that method. It would be pretty interesting if that worked where frmMain.Text did not. It would be replacing your use of a base class property with a derived class method. I would only do this as a test, because it really shouldn't work, but if it did, it would be diagnostic.

Doing that does not provide an error. This is weird.

[theryan722]

So, you reference things like your example, and wherever you do that you get an exception, but only in the release version. Is that right?

Your example is setting a property of a class that frmMain is derived from, since .Text is a property of Form (or Control, or some other base class). Is this true of EVERY place where you are getting the exception?

The first thing I would try would be to create my own method on frmMain, something like this:

Public Sub SetText(newText As String)
 Me.Text = newText
End Sub

and call that method. It would be pretty interesting if that worked where frmMain.Text did not. It would be replacing your use of a base class property with a derived class method. I would only do this as a test, because it really shouldn't work, but if it did, it would be diagnostic.

However looking through my code, I make calls to other methods on frmMain, and those provide an error. I can't seem to win here.

[theryan722]

Also, when I switch to release mode, a lot of my forms disappear and only the class file is left, but the forms reappear when I switch back to debug.

[NeedSomeAnswers]

Hello, there are no errors in my project when in debug mode. When I switch it to release mode, I get a lot of "Reference to a non-shared member requires an object reference" errors.

So does you project Build in BOTH debug and Release mode ?

Are the errors happening just when you run it in release mode ?

and also what error handling do you have in place to capture these errors? can you post some code of where one of your errors is occurring?

[theryan722]

They are designer errors in Release Mode, I cannot even build it. When you switch back to debug mode there is nothing wrong.

[SJWhiteley]

Start a new project and make sure you can build in Debug and Release. Essentially you want to strip down the project to the one thing which causes the problem. If that means copying stuff to a new project, then you may have to do that.

Do you have user controls in the project?

[NeedSomeAnswers]

They are designer errors in Release Mode, I cannot even build it. When you switch back to debug mode there is nothing wrong.

Are you referencing any dll's or ocx's actually in your debug folder?

[theryan722]

I'm referencing some other projects, and some DLLs, but they work fine in my other projects in release mode. The errors are displaying when I make a call to frmMain (i.e. frmMain.Textbox1.Text = "text here"). It gives me the non shared member error and reference error. It does not do this in debug mode.

[NeedSomeAnswers]

I'm referencing some other projects, and some DLLs,

Yes but where?

i was asking specifically do you reference any other dll's that live in your debug folder?

[theryan722]

I reference them from an outside folder and the studio then places them in the debug folder when I build it.

[NeedSomeAnswers]

ok another thing to check,

go into Configuration manager under your Build menu, there will be 2 comboboxes along the top. In the one that is labeled - "Active Solution Configuration" if you switch between Debug and Release in that combo, does it change the platform in the list below?

[theryan722]

The platform remains as Active (Any CPU)

[Shaggy Hiker]

However looking through my code, I make calls to other methods on frmMain, and those provide an error. I can't seem to win here.

Those other methods on frmMain, are they methods you wrote?

This is certainly an odd problem. You would expect that, at the very least, debug and release would work the same, and they usually do. It appears that the compiler is getting confused between the default instance and the class type. This confusion may be more prevalent in the release mode because the debug mode might include more mapping. More likely, I just made that up and it's nonsense. The compiler is likely keeping a symbols table to know what is what. That table seems to be getting an incorrect bit of data, which I think is where SJW is coming from with the suggestion to try a different project.

You mentioned that you were referencing other projects. Could there be a different frmMain in any of those?

[theryan722]

Nope I wish haha. And yes some of those methods are mine in frmMain. I mean, I don't desperately need it to be in release mode, except for the fact that most of my other projects I publish in release mode, but whatever.

[NeedSomeAnswers]

That table seems to be getting an incorrect bit of data, which I think is where SJW is coming from with the suggestion to try a different project.

Hmm yep i tend to agree with everyone else something is screwy but its not obvious so it might be best to create a brand new project, make sure it starts in release mode and just copy stuff across bit by bit.

[Shaggy Hiker]

I would say that a new project, at least to test this, would be a good thing to do. You can use Import Existing to bring in pretty much everything. The danger with leaving it in debug mode is that you don't understand what the problem is. If it's a bug in the compiler, that's actually fine (it may go away in a new release of VS). The worst case scenario is that your installation of VS has become corrupted, in which case life could get stranger and stranger.

On the other hand, I don't think I have any other suggestions. I've never seen anything quite like this. The error itself is rare, but unremarkable. The fact that it happens only in Release mode is more disturbing.