0

In Visual Studio Express 2013 erstelle ich ein benutzerdefiniertes Steuerelement namens "AddressVerifier", das über eine benutzerdefinierte Schaltfläche namens "CustomButton" verfügt. Jedes Mal, wenn ich das Formular ändere, auch wenn ich nur ein Label verschiebe, ändert es die Datei AddressVerifier.Designer.vb, die wie gezeigt einen Kompilierungsfehler erzeugt. Wenn ich eine der beiden ersten Fixes auswähle, kompiliert es alles und alles ist gut, bis ich das Formular erneut modifiziere, dann entfernt es das Update für die nächste Kompilierung.Typ nicht definiert, Visual Studio Express 2013

Ich bin praktisch GEWISSEN das ist ein Fehler, aber gibt es einen Workaround?

enter image description here

+1

Veröffentlichen Sie keine Bilder Ihres Codes. Das macht es schwieriger für uns, Ihnen zu helfen, was bedeutet, dass Sie weniger wahrscheinlich eine gute Antwort bekommen. –

+0

Jedes Mal, wenn Sie Änderungen am Formular vornehmen, wird die gesamte Designer-Datei erneut ausgegeben (im Post wird angegeben, dass es sich um den AddressVerifier-Designer handelt, der jedoch eher wie ein Formular aussieht * mit * dem Steuerelement). Die verlorene Referenz hängt wahrscheinlich davon ab, wie das 'CustomButton'-Projekt enthalten ist und/oder der Namespace – Plutonix

+0

Joel, ich habe ein Bild von Code WITH mit Fixes gepostet. Deshalb würde nur ein Bild ausreichen. Plutonix, das ist seltsam für mich, dass wenn ich eine der angebotenen Fixes auswähle, es funktioniert, aber es fügt das Problem zurück, wenn ich das Formular modifiziere. Das Problem scheint zu sein, dass der Formular-Designer Code ändert, um einen Kompilierungsfehler zu erzeugen. AddressVerifier ist ein Formular, das als benutzerdefiniertes Steuerelement verwendet werden kann, aber CustomButton enthält. Im Wesentlichen ist es ein benutzerdefiniertes Steuerelement in einem benutzerdefinierten Steuerelement. – PaulOTron2000

Antwort

1

Dies aufgrund der Namensgebung sein kann. Es scheint, dass Sie einen Typ und einen Namensbereich haben, die beide AddressVerifier aufgerufen werden. Die IDE verwendet den Namen des Namespace im Code, aber der Compiler interpretiert ihn als Typ. Die Lösung besteht darin, nicht denselben Namen für zwei Dinge im selben Kontext zu verwenden.

BEARBEITEN: Der Vorschlag zum Hinzufügen des Qualifikationsmerkmals Global besteht darin, den Compiler zu zwingen, den Namen als Namespace und nicht als Typ zu interpretieren. Es wird zurückgesetzt, wenn die Design-Codedatei neu generiert wird, da die IDE nicht jeden möglichen Typ und Namespace auf Namenskonflikte untersucht, sondern nur davon ausgeht, dass Sie Dinge so benannt haben, dass sie nicht vorkommen. Es könnte als Einschränkung, aber nicht als Fehler in der IDE betrachtet werden.

+0

Das war es total. Mein Namensraum und meine Klasse waren beide gleich. Änderte den Klassennamen in AddressVerifyClass und Boom, alles weg. Ich wette, mein Fehler, dies zu sehen, scheint ziemlich lahm zu sein, aber hier ist ein Geständnis: Ich bin vielleicht der "flinkste Weg durch den .NET-Programmierer", dem Sie jemals begegnen werden. Ich war ein VB6-Programmierer vor Jahren (und ich war ziemlich gut), aber änderte Karriere vor .net und jetzt mache ich so ziemlich alles mit gutem Beispiel, nur Software für mein eigenes Geschäft zu machen. – PaulOTron2000

+0

Ich denke, der beste Weg, diese Art von Problem zu vermeiden, besteht darin, Ihre Projekte und damit Ihre Stammnamensräume immer mit einem "Geschäftsnamen" zu benennen. Wenn ich zum Beispiel ein Projekt namens AddressVerifier erstellen würde, wäre der tatsächliche Projektname und der Root-Namespace "Wunnell.AddressVerifier". Ich würde dennoch empfehlen, den gleichen Namen für zwei verschiedene Dinge im selben Kontext zu vermeiden. Ich würde auch vorschlagen, dass Sie Ihre Namen hier etwas genauer betrachten und zwei verschiedene Namen finden, die maximal beschreibend sind, da "AddressVerifyClass" eher zweifelhaft ist. – jmcilhinney