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.
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.
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.
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.