Wenn Sie ein Abonnement des Magazins 'DATENBANKENTWICKLER' besitzen, können Sie sich anmelden und den kompletten Artikel lesen.
Anderenfalls können Sie das Abonnement hier im Shop erwerben.
Tipps und Tricks zu Visual Studio
Wer von Access zu Visual Studio wechselt, stößt immer wieder auf neue Herausforderungen in dieser neuen, im Vergleich zur Access-Entwicklungsumgebung viel komplexeren Welt. In der heutigen Ausgabe der Reihe Tipps und Tricks zu Visual Studio schauen wir uns einmal an, wie Sie ein Projekt umbenennen. Unter Access haben Sie dazu die Datei und gegebenenfalls noch das VBA-Projekt umbenannt. Unter Visual Studio ist eine ganze Menge mehr zu beachten: Allein, das wir nicht nur eine einzige Datei haben, sondern ganze Ordner voller Dateien und uns auch noch mit zu erstellenden .exe-Dateien und Dingen wie Namespaces herumschlagen müssen, macht die Aufgabe recht komplex ...
Komplettes Projekt umbenennen
Während der Erstellung der Beispielprojekte für dieses Magazin ist es recht häufig passiert, dass ein Projekt nicht gleich den richtigen Namen hatte. Mit dem Projektnamen legt man beim Erstellen eines Projekts natürlich auch gleich noch eine Menge weiterer Benennungen fest, zum Beispiel verschiedene Ordner und Pfade, den Namespace et cetera. Also schauen wir uns einmal an, welche Schritte nötig sind, um ein solches Projekt umzubenennen. Wir sind es zuerst einmal naiv angegangen und haben einfach den Ordner, in dem sich alle Projektdateien befinden, die .sln-Datei und den Ordner mit den weiteren Projektdateien in Bestellverwaltung umbenannt (siehe Bild 1). Den Rest werden wir schon in Visual Studio ändern können, haben wir uns gedacht.
Bild 1: Projektordner mit .sln-Datei und Unterordnern
Aber weit gefehlt: Das Öffnen der .sln-Datei per Doppelklick lieferte die Meldung aus Bild 2 und anschließend einen Projektmappen-Explorer mit dem Hinweis, dass das Laden fehlgeschlagen ist. Was nun?
Wenn das Laden fehltschlägt, liegt das meist daran, dass die gewünschte Datei nicht an Ort und Stelle ist, was uns ein Blick in das Ausgabefenster dann auch bestätigte.
Da Visual Studio keine Möglichkeit bot, die .sln-Datei zu öffnen, haben wir diese also in einem handelsüblichen Editor angezeigt. Und hier tauchten dann auch gleich einige Erwähnungen des vorherigen Projektnamens RibbonsUndWindows auf (siehe Bild 3). Tauschen wir diesen also an den relevanten Stellen gegen Bestellverwaltung aus, sieht die betroffene Zeile wie folgt aus (auch den Projektnamen haben wir gleich angepasst):
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Bestellverwaltung", "BestellverwaltungBestellverwaltung.csproj", "{2DA961CE-96A6-4CAF-AC72-05D5CF4C6196}" Das der nächste Versuch, das Projekt über die .sln-Datei in Visual Studio ebenfalls fehlschlägt, hätten wir vorausahnen können: Wir haben ja in der obigen Zeile auch gleich den Namen der .csproj-Datei auf Bestellverwaltung.csproj geändert, dies aber noch nicht im Windows Explorer nachgeholt. Gegegebenenfalls müssen Sie auch noch andere Dateien umbenennen, deren Name den alten Projektnamen enthält.
Erste wenn wir auch noch diese Datei im Windows Explorer umbenennen, lädt Visual Studio das komplette Projekt (siehe Bild 4). Dies dauert zwar ein paar Sekunden, aber vielleicht hat Visual Studio ja direkt noch ein paar Änderungen bezüglich des Projektnamens im Code vorgenommen.
Der erste Test zeigt, dass das Projekt läuft, aber ein Blick in den Code offenbart, dass tatsächlich wohl nur die Ordner, die beiden Dateien mit der Endung .sln und .csproj sowie das Projekt selbst umbenannt wurden (siehe Bild 5). Der Namespace hat seinen Namen noch behalten.
Außerdem zeigt ein Blick in den Ordner bin|Debug, das auch die erstellten Dateien, also etwa die .exe-Datei, noch den alten Namen enthalten. Kümmern wir uns zunächst einmal um diese Dateien. Dazu brauchen Sie nur die Eigenschaften des Projekts zu öffnen, indem Sie im Projektmappen-Explorer doppelt auf den Eintrag Properties unterhalb des Projektnamens klicken. Hier stellen Sie direkt auf der ersten Seite Anwendung den Wert der Eigenschaft Assemblyname auf Bestellverwaltung ein (siehe Bild 6). Ein Test zeigt, dass die erstellten Dateien nun mit dem Namen Bestellverwaltung beginnen – also Bestellverwaltung.exe et cetera. Da liegt nun die Versuchung nahe, auch gleich die Eigenschaft Standardnamespace im gleichen Dialog auf Bestellverwaltung zu ändern. Also probieren wir dies aus und erstellen das Projekt erneut.
Nun stoßen wir auf Probleme: Zwar hat diese Änderung nicht den Namespace in den durch den Benutzer erstellten geändert. Aber es gibt ja gegebenenfalls (und speziell in den Projekten, die wir in den Beispielen der aktuellen Ausgaben erstellen) auch einige Klassen und Dateien, die automatisch generiert werden. Dazu gehören die Dateien des Entity Data Models, in unserem Fall zum Beispiel die Datei BestellverwaltungModel.Context.cs (siehe Bild 7). Offensichtlich wird deren Neugenerierung beim Anpassen des Standardnames in den Projekteigenschaften automatisch angestoßen. Dies wird auch offensichtlich, wenn Sie dies erneut versuchen und testweise den Wert der Eigenschaft Standardnamespace auf Bestellverwaltung1 ändern. Die längere Anzeige der Sanduhr deutet darauf hin, dass da im Hintergrund gearbeitet wird – eben, indem der Namespace des Entity Data Models angepasst wird. Den Beweis dafür liefert dann auch die Meldung aus Bild 8.
Dies war die Leseprobe dieses Artikels.
Melden Sie sich an, um auf den vollständigen Artikel zuzugreifen.