System.ObjectDisposedException on GoView object

We are using GoDiagram 2.4.1.1. We have been planning to move to 2.6.2.2, but everything has been working fine and there has been no major reason to move so far – but we are very willing to move to the new version if it would solve this issue.

We have just released our first build with the .NET Framework 2.0, and with this build we started having an intermittent System.ObjectDisposedException on the GoView object. It is as if the GoView object has been disposed and we are trying to reference it after disposing of it. There is no where in our code where we call GoView.Dispose(), so we are unsure how it comes to be disposed.
We have been unable to come up with a sequence of steps that will consistently reproduce the problem. It seems to happen most frequently whenever we Show or Hide the MDI form containing the GoView, but it probably happens only 1 or 2 times out of every 100 tries.
Have you ever heard of such a problem before? Should version 2.4.1.1 have worked with the .NET Framework 2.0, or is it only for .NET 1.0/1.1?
If we move to GoDiagram 2.6.2.2, do you believe that this problem may go away?
Thanks in advance,
-Darren Jones

I can't find any record of such a problem with any version of GoDiagram.

I don’t know why changing to a newer version would make a difference, but it might be worth a try.

I believe 2.4.1.1 should work with .NET 2.0. But I’m always surprised by incompatibility problems with Microsoft software.

You could try the assembly compiled for .NET 2.0: (deleted reference to obsolete version)

I have this problem all the time, and I have to wipe out all my obj directories and any .suo files. Very annoying.

That sounds like Visual Studio is getting its temporary/intermediate files corrupted.

Do you have any idea why that might happen with a class derived from GoView? I see the problem intermittently, but it’s consistently with those classes.

Do you use the Visual Studio Form designer on forms that contain instances of your GoView-inheriting class? I know there are problems with the designer when it needs to depend on code that is in the same solution. You’re supposed to put such custom Controls (such as your class inheriting from GoView) in a separate project in order to reduce the problems. But I usually don’t bother and I live with the errors that result, such as when trying to design the form when I haven’t compiled the code yet.

Also, what version of Visual Studio and GoDiagram are you using?

No, actually, I have my SuperImprovedGoView in another project.

VS2005 with the most recent SP, and GoDiagram.NET 2.5.1.

OK, but I’m just saying that I’ve run into problems with VS2005 even when the SuperImprovedGoView was in a different project, but it was still part of the same solution.

And it's happened to me when my control wasn't even inheriting from GoView but from another control.
But maybe we're talking about different problems. The original topic seems to be talking about something I've never seen. Your recent comments seem to be talking about design time problems in Visual Studio, but perhaps I have misinterpreted your meaning.
So you are seeing an ObjectDisposedException at run-time? And this happens even when Visual Studio is not involved in any manner (i.e. you are not running from inside Visual Studio, even without the debugger)?

I apologize. My colleagues insisted that GoView.Dispose() would crash at runtime. This is false. The crash during design time is sporadic, and I myself have not been able to replicate it in a convincing way that would even show that it’s your bug. I’ve told the developer who insists that there’s a bug to replicate it or forget about it.