Folgende Schritte sind grundsätzlich sinnvoll, wenn man .NET Framework-App auf .NET-Unterbau upgraden will.
Anmerkung: Hier arbeite ich ein VB.NET-Projekt durch, aber das sollte genauso bei C#-Projekten klappen.
Baut Euch erstmal eine gute, leere .NET-Projektvorlage und macht sie in Visual Studio verfügbar, z.B. mit dieser Anleitung.
In der .vbproj-Datei habt Ihr ungefähr folgenden ersten Abschnitt:
Behaltet in der .vbproj auf jeden Fall den Tagbei, auch wenn es falsch scheint, das so zu lassen. Wenn Ihr das hier oder im Designer ändert, gibt es später bei Programmstart Designerprobleme und Fehlermeldungen in der Ausgabe des Direktfensters, zumindest mit .NET 7. Das Problem habe ich bereits bei Microsoft gemeldet.
Einen Versionstag sollte man einbauen, wenn man Versionsnummern verwendet, denn derzeit wird das nicht im Designer wie in .NET-Framework-App angeboten, z.B.
Auch sollte derTag dabei sein, damit nicht zuviel Müll von Haus aus geladen wird, siehe hier:
Visual Studio – Empfohlene Einstellungen
Stellt in den Projekteigenschaften auch Option Strict auf On und alle Warnungen auf Fehler:
Nachdem Ihr nun in VS Eure Vorlage zur Verfügung habt, nutzt diese, um ein leeres Projekt zu erzeugen. Eine eventuell vorhandene, leere Startformulardatei löscht Ihr, da Ihr ja bereits alle Dateien im alten Projekt habt, die Ihr braucht. Kopiert nun die ganzen .vb-Dateien, ggf. mit vorhanener Ordnerstruktur des alten .NET-Framework-Projekts in das Verzeichnis des neuen .NET-Projekts. Danach sind die Dateien sofort verfügbar und eingebunden.
Der nächste Schritt sind DLL- und Nuget-Paket-Abhängigkeiten.
Nuget-Pakete müsst Ihr im neuen Projekt über Nuget selbst wieder hinzufügen/installieren. Alternativ könnt Ihr auch die notwendigen DLLs manuell ins EXE-Verzeichnis kopieren und diese dann wie andere DLLs verlinken.
DLL-Abhängigkeiten können nicht mehr über die Projekteigenschaften hinzugefügt/verwaltet werden.
Im Projektmappen-Explorer gibt es unter dem Projektnamen einen Punkt
So kommt Ihr in den Referenzmanager, von wo aus Ihr Eure Verweise hinzufügen könnt.
Das Entfernen von Verweisen geht anscheinend nur noch über den Projektmappen-Explorer, also nicht mehr über den Referenzmanager. Gewöhnungssache.
Wer ein Programmsymbol für die EXE hinterlegen will, kann dies in den Projekteigenschaften bei Anwendung -> Ressourcen -> Symbol hinterlegen
Ich teile meine Form-Dateien gerne auf, sodass pro Datei inhaltlich verschiedene Code-Kategorien abgearbeitet werden. Neben dem Designercode habe ich dann in je eigenen Dateien z.B. Code zur GUI-Manipulation, Anweisungen an andere Klassen, Abfragen vom Benutzer, etc.
Die
Dabei kann die FormX.vb im selben Verzeichnis wie die anderen Dateien sein, da kommt VS nicht durcheinander.
Anmerkung: eine
Kompiliert Euer Programm und das war's.
Anmerkung: Hier arbeite ich ein VB.NET-Projekt durch, aber das sollte genauso bei C#-Projekten klappen.
Baut Euch erstmal eine gute, leere .NET-Projektvorlage und macht sie in Visual Studio verfügbar, z.B. mit dieser Anleitung.
In der .vbproj-Datei habt Ihr ungefähr folgenden ersten Abschnitt:
Behaltet in der .vbproj auf jeden Fall den Tagbei, auch wenn es falsch scheint, das so zu lassen. Wenn Ihr das hier oder im Designer ändert, gibt es später bei Programmstart Designerprobleme und Fehlermeldungen in der Ausgabe des Direktfensters, zumindest mit .NET 7. Das Problem habe ich bereits bei Microsoft gemeldet.
Einen Versionstag sollte man einbauen, wenn man Versionsnummern verwendet, denn derzeit wird das nicht im Designer wie in .NET-Framework-App angeboten, z.B.
Auch sollte derTag dabei sein, damit nicht zuviel Müll von Haus aus geladen wird, siehe hier:
Visual Studio – Empfohlene Einstellungen
Stellt in den Projekteigenschaften auch Option Strict auf On und alle Warnungen auf Fehler:
Nachdem Ihr nun in VS Eure Vorlage zur Verfügung habt, nutzt diese, um ein leeres Projekt zu erzeugen. Eine eventuell vorhandene, leere Startformulardatei löscht Ihr, da Ihr ja bereits alle Dateien im alten Projekt habt, die Ihr braucht. Kopiert nun die ganzen .vb-Dateien, ggf. mit vorhanener Ordnerstruktur des alten .NET-Framework-Projekts in das Verzeichnis des neuen .NET-Projekts. Danach sind die Dateien sofort verfügbar und eingebunden.
Der nächste Schritt sind DLL- und Nuget-Paket-Abhängigkeiten.
Nuget-Pakete müsst Ihr im neuen Projekt über Nuget selbst wieder hinzufügen/installieren. Alternativ könnt Ihr auch die notwendigen DLLs manuell ins EXE-Verzeichnis kopieren und diese dann wie andere DLLs verlinken.
DLL-Abhängigkeiten können nicht mehr über die Projekteigenschaften hinzugefügt/verwaltet werden.
Im Projektmappen-Explorer gibt es unter dem Projektnamen einen Punkt
Abhängigkeiten
. Da ein Rechtsklick drauf und da Projektverweis hinzufügen.So kommt Ihr in den Referenzmanager, von wo aus Ihr Eure Verweise hinzufügen könnt.
Das Entfernen von Verweisen geht anscheinend nur noch über den Projektmappen-Explorer, also nicht mehr über den Referenzmanager. Gewöhnungssache.
Wer ein Programmsymbol für die EXE hinterlegen will, kann dies in den Projekteigenschaften bei Anwendung -> Ressourcen -> Symbol hinterlegen
Ich teile meine Form-Dateien gerne auf, sodass pro Datei inhaltlich verschiedene Code-Kategorien abgearbeitet werden. Neben dem Designercode habe ich dann in je eigenen Dateien z.B. Code zur GUI-Manipulation, Anweisungen an andere Klassen, Abfragen vom Benutzer, etc.
Die
FormX.Designer.VB
wird dabei automatisch als Subdatei der FormX.vb
aufgeführt, es sei denn sie wird umbenannt (ich nenne sie nur Designer.vb, da jedes Form bei mir in einem eigenen Dateiordner ist, daher keine Namenskonflikte). Wer mehrere Dateien von einer anderen abhängig machen will, sodass sie im Projektmappen-Explorer als Subdatei von einer anderen erscheinen soll, kann das hier in der .vbproj-Datei hinterlegen:Dabei kann die FormX.vb im selben Verzeichnis wie die anderen Dateien sein, da kommt VS nicht durcheinander.
Anmerkung: eine
ItemGroup
kommt nicht in eine PropertyGroup
, sondern außerhalb dieser, also z.B. darunter.Kompiliert Euer Programm und das war's.
Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.
Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.