Migrieren einer WPF-App (.NET Framework 4.6.1) zu .NET 6.0

  • Allgemein

Es gibt 20 Antworten in diesem Thema. Der letzte Beitrag () ist von kafffee.

    Migrieren einer WPF-App (.NET Framework 4.6.1) zu .NET 6.0

    Hallo liebe Community,

    ich habe mich nun (fast) durchgerungen, mein Projekt, welches aktuell in .NET Framework 4.6.1 vorliegt, nach .NET 6.0 zu migrieren, da die Mehrheit der Verweise oder auch NuGet-Pakete, die eingebaut sind bzw. werden sollen, dies erfordern...

    Bin dabei auf folgende Seite gestossen:

    docs.microsoft.com/de-de/dotne…desktop/example-migration

    Jetzt meine Frage: Ist das was Grösseres oder ratet ihr mir aus anderem Grund davon ab? Was muss ich beachten? Oder sollte ich zu .NET Core statt .NET 6.0 wechseln, denn z.B. die bass.net.dll hat nur folgenden Support:

    "Includes support for .NET Framework 2.0/4.0/4.5, .NET Core 2.1/3.0, .NET Standard 2.0, and Mono/Xamarin"

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „kafffee“ ()

    Hallo,
    es kommt einfach darauf an, wie groß dein Projekt ist und wie viele (externe) Abhängigkeiten du hast. Die Breaking Changes geben eine gute Übersicht, wo du an deinem Programm noch mal Hand anlegen musst. Probier es halt aus, vielleicht brauchst du ja nur ein paar Nuget-Pakete und schon läuft es.

    Mit Namen hatte es MS ja noch nie. .NET Core ist .NET 6. Das Core ist seit .NET 5 aus dem Namen verschwunden :)

    Da denkst du etwas verkehrt, da die Library für .Net Standard 2 verfügbar ist, sollte die unter .Net 6 laufen:
    .NET Standard

    Hi @kafffee,

    du kannst auch mal den .NET Upgrade Assistant testen. Eventuell macht der schon einen Großteil der Arbeit für die:
    dotnet.microsoft.com/en-us/platform/upgrade-assistant

    Kleinere Nacharbeiten muss man eventuell schon noch machen... Libraries waren bei mir bisher kein Problem.
    NETworkManager - A powerful tool for managing networks and troubleshoot network problems!

    Vollzitat des direkten Vorposts an dieser Stelle entfernt ~VaporiZed

    Ja ich weiss, siehe der Link im Post#1. Was ich noch nicht so ganz verstehe da gibt es einen Abschnitt "Vorbereitungen". Muss ich den erst durcharbeiten oder kann ich direkt den Upgrade Assistent starten? Sollte ich inkompatible Verweise und Pakete vorher oder hinterher austauschen?

    Edit:
    @BornToBeRoot
    Hab mal vorab mit einem kleinen Testprogramm, das über die gleichen Libraries verfügt, das ausprobiert. Sind dann doch einige Fehler, obwohl alles laut Upgrade Assistant erfolgreich war. Fünf Fehler konnte ich schon beseitigen, den Rest könnt ihr in dem angehängten Screenshot sehen.

    Kann mir da einer unter die Arme greifen die Fehler zu beseitigen, ich hab da keine Idee mehr...?

    Vielleicht auch mal die Frage an @Nofear23m:

    Du hast das doch bestimmt auch schon gemacht, dein Multiproject-MVVM-Template nach .NET 6.0 migriert.

    Es scheint als ob alle Dateien, die von mir selbst erstellt wurden (in diesem Fall im ViewModel und in der View), nicht im jeweiligen Namespace gefunden werden. Hab schon alle Projekt neu erstellt, weiters fällt mir jetzt auch nichts ein... Kannst du mir helfen?

    OK, hab mal bisschen rumgespielt und hab auf eine der Warnungen, die man jetzt im Screenshot nicht sieht, geklickt, dann neu erstellt und schwups, die Fehler waren weg :)

    >>> Oje, und nachdem ich das Problem in Edit 2 gelöst hab, tauchen die Fehler wieder auf :(

    Edit2:
    Für die ersten vier Fehler habe ich glaub eine Lösung gefunden, hier:

    stackoverflow.com/questions/67…not-defined-error-bc30002

    Man soll was im vbproj-file verändern. Komme ich denn da irgendwie im Projektmappenexplorer ran oder muss ich mir die einfach in einen Texteditor laden und dann mit den Änderungen speichern? Und muss ich das für alle vier Projekte machen oder nur für das App-Projekt?

    Edit3:
    OK auch für das hab ich ne Lösung gefunden und es funktioniert:
    https://stackoverflow.com/questions/5129090/how-to-edit-csproj-file

    Bilder

    • screenshot net6 upgrade.png

      362,09 kB, 2.560×1.080, 77 mal angesehen

    Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von „kafffee“ ()

    Hast du mal Rechtsklick auf das Projekt gemacht und auf "Projektmappe neu erstellen" geklickt? Wenn du schreibst das es bereits funktioniert hat.

    Bei den Warnungen kannst du mal schauen ob es mittlerweile Pakete gibt die .NETCore oder .NET 5/6 gebaut wurden.

    In der Projektdatei kannst du übrigens auch das Target Framework (ist bei dir .net 6.0 / Windows 7) setzen:

    Ich hab bei mir (c#) folgendes drin für mind. Windows 10 1809 x64:

    C#-Quellcode

    1. ​
    2. <Project Sdk="Microsoft.NET.Sdk">
    3. <PropertyGroup>
    4. <OutputType>WinExe</OutputType>
    5. <TargetFramework>net6.0-windows10.0.17763.0</TargetFramework>
    6. <RuntimeIdentifiers>win10-x64</RuntimeIdentifiers>
    7. <SelfContained>false</SelfContained>
    8. </PropertyGroup>
    9. </Project>



    SelfContained macht deine kompilierte Anwendung kleiner, setzt aber die dotnet desktop runtime auf dem Client voraus.
    NETworkManager - A powerful tool for managing networks and troubleshoot network problems!

    @BornToBeRoot

    Ja neu erstellt hab ich, das war auch das erste das ich gedacht hab. Es sind ja vier Projekte:

    App, Model, View, ViewModel

    Die hab ich alle zur Sicherheit neu erstellt und auch die komplette Projektmappe...

    Die Warnungen sind denke ich die kleinere Herausforderung. Wenn ich dann mein grosses Projekt migrieren werde ich zuvor alle Abhängigkeiten entfernen, sind nur drei bis jetzt, und dann neu installieren das scheint mir einfacher....

    Was bringt es ein TargetFramework zu setzen?

    Wie kommst du bei mir auf Win7? Ich benutze Win10 und das soll dann das fertige Projekt auch wenns fertig ist...

    Das mit dem self Container ist gut zu wissen für die Zukunft.

    Beim aktuellen Projekt setze ich aber eher auf Portierbarkeit...

    kafffee schrieb:

    Was bringt es ein TargetFramework zu setzen?

    Damit kannst du eine mindestversion setzen die deine App brauch. Wenn du z.B. auf Schnittstellen zugreifst die es ab Windows 10 1809, 1909, 20H2, 21H2 gibt...

    kafffee schrieb:

    Wie kommst du bei mir auf Win7? Ich benutze Win10 und das soll dann das fertige Projekt auch wenns fertig ist...

    In der Meldung zu den Paketen steht "Projektzielframework .net6.0-windows7.0" - das musste standard sein wenn du nichts anderes setzt.
    NETworkManager - A powerful tool for managing networks and troubleshoot network problems!

    Ich mische hier mal mit

    Sag mal @kafffee, wie hast du denn "Migriert". Und Warum Migrieren?
    Du hast mir das Projekt geschickt und da war sooooo viel drinnen was da nicht hingehört.

    Zudem ist das Projekt so gut wie leer, bis auf das typische MVVM Grundgerüst.
    da frage ich mich was es da zu Migrieren gibt. Da erstelle ich doch ein neues Projekt und baue dieses auf.

    Zudem solltest du dich mal damit Beschäftigen was die Unterschiede zwischen .Net Framework und .Net 6 (vormals .Net core) sind.
    UND was für eine Rolle da nun .Net Standard spielt. Denn dein Model wurde mit .Net 6-windows kompiliert. What?
    Wozu wenn da nur POCO Klassen enthalten sind. Das Projekt kann ich als reines .Net Standard2 Projekt erstellen. Da landen ja nur Models drinnen.
    Oder zumindest als normales Cross-Plattform fähiges .Net core (ohne dem -windows dran).

    Anbei das "migrierte" Projekt.

    Grüße
    Sascha
    Dateien

    • MigrationTest.zip

      (568,44 kB, 45 mal heruntergeladen, zuletzt: )
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    @Nofear23m

    Ich hab den Upgrade Assistent zum migrieren verwendet.

    Das Projekt das ich dir da geschickt hab war ein blosses Testprojekt. Deswegen so viel unnötiges Geraffel drin.. . Hab ich allerlei Sachen mit ausprobiert, u. A. das Migrieren...

    Deswegen: Wie bist du dabei vorgegangen und wo lag der Fehler? Dann kann ich das bei meinem Hauptprojekt hoffentlich selber...

    Warum das Model jetzt mit. NET 6 kompiliert war - keine Ahnung... Hab da allerlei versucht das selber hin zu bekommen...

    Der Migrationsassistent ist mist.

    Erstelle eine Projektmappe und bau alle vier Projekte leer auf.

    Ein Quasi fertiges Projekt zu Migrieren ist eintach Müll wenn man nicht genau weis woran man schrauben muss wenns nicht klappt.

    Da hat man gleich mal 100+ Fehler ohne einen Ansatz wo genau das Problem ist.
    Dann muss man schon genau schaun wo nun das Problem ist.

    Andere Frage: Warum willst du denn unbedingt Migrieren. Ich sehe für eine Desktopanwendung jetzt keinen Grund. Ider gibt es einen?

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    @Nofear23m

    Erstmal danke für die schnelle Antwort. Ich dachte mir schon dass da tausend Probleme anfallen würden dabei... Deswegen auch das Testprojekt.

    Du meinst also ich soll einfach ein neues Projekt erstellen und dann sukzessive jede Datei meines Projektes reinkopieren, wenn ich dich richtig verstehe? Oder gibt es da irgendwelche Kniffe wie man das richtig macht?

    Jou es gibt Gründe warum ich das möchte...

    Zuerst möchte ich Libraries und Nuget-Pakete verwenden, die unter 4.6.1 nicht laufen.
    Das ist der Hauptgrund.

    Dann möchte ich das Ganze, wenn ich schon dabei bin, zukunftssicher haben.

    Aber da muss ich mich erstmal auch noch genau informieren was denn nun
    . Net, . NET Core und. NET Standard sind und was die alles können und wo die Unterschiede liegen...
    Und was es mit der UWP und Cross-Platform Sache so auf sich hat...

    Ok, klären welche NuGet Pakete.

    Ich denke zu brauchst ja nur diese Bass, und die gibt als NuGet für .Net.
    Alle Librarys die unter .Net Standard ich glaube bis zur 2.0 aber da bin ich mir nicht ganz sicher erstellt wurden kannst du auch unter .Net 4.8 einbinden.

    Zukunftssicher?
    Naja, ist beides nicht wirklich. Spätestens mit .net 8 willste dann wieder Migrieren, aber das ist ein anderes Thema.

    Können tuts nicht mehr. Unter der Haube ja, das wirst du aber bei deinem Projekt nicht merken.

    Cross Plattform schlag dir gleich wieder aus dem Kopf. Das gilt nicht für WPF oder WinForms. Du kompilierst mit "net 6.0-windows". Fällt dir was auf?

    Deshalb ja meine Frage warum du migrieren willst. Bitte nicht migrieren weil es ja was neues gibt. .Net ist kein Leasingvertrag.

    Wenn ich ein neues Projekt anfange (und ich weis was ich da mache und was .net 6 überhaupt genau ist und was nicht) dann mach ich das mit net 6, aber alles was bereits da ist versuche ich nicht mit der Brechstange zu verbiegen. Wozu wenn es keinen Mehrwert bringt.

    Zumindest nicht wenn es nicht unbedingt notwendig ist weil ich z.b. ein Framework oder ein Pattern verwenden möchte welches das erfordert.

    Zumindest studiere mal genau .net Framework, .net Standard und .net Core und wie das alles zusammenspielen kann/muss und was dabei die Unterschiede sind und was man beachten muss. Kann sehr verwirrend sein anfangs, glaub mir.
    Und wenn du das hast dann schau dir mal was es mit der neuen Versionierung von MS im Zusammenhang mit Long Term Support von MS mit .net x hat. Das geht gleich in einem Rutsch und hilft zu verstehen was ich oben mit .net 8 meinte.

    Grüße
    Sascha

    PS: Verlier dich nicht darin, mach dein Programm fertig und schau das es gut und Fehlerfrei ist. Brings erstmal auf die Straße, alles weitere kannst du mal überlegen wenn dir langweilig ist. :)
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    @Nofear23m

    Neben der Bass.dll brauch ich noch fünf oder sechs andere Abhängigkeiten/Nuget Pakete, ich hab jetzt die genauen Wortlaute der ganzen Namen vergessen, aber darunter sind:

    WindowsAPICodePack
    Discogsclient
    Sandreas.AudioMetaData

    Die ersten zwei stellen kein Problem dar, bei der dritten wirds schwierig. Wenn ich das richtig verstanden habe, ist, wenn man auf der Nuget Paket-Seite auf Framework klickt, das dunkelblau hinterlegte das optimale Framework, ist aber mit dem hellblau hinterlegten kompatibel....

    Hab mich mal über die Unterschiede zwischen. NET Core, . NET Framework und. NET Standard informiert. Wenn ich das richtig verstanden habe grob vereinfacht (korrigiere mich bitte wenns nicht stimmt)
    -Core am besten für plattformübergreifende Apps, also auch auf Linux oder Mac lauffähig (wobei ich noch net verstanden hab, wie das genau ablaufen soll...) - das hat mich aber am meisten beeindruckt

    -Framework - wenn mans "eilig hat" und nicht so sehr auf Zukunft setzen muss

    -Standard: Wenn du z. B. eine DLL schrieben willst, die auf Core und Framework laufen soll

    Somit wäre für mich der Workaround, mal zu checken ob meine Nuget Pakete denn Standard unterstützen, und wenn ja, einfach nochmal selbst eine kleine DLL sozusagen als "Schnittstelle" (oder ich glaub man nennt es "Wrapper") dazwischen mach....

    Andererseits hört sich Kompatibilität mit Linux oder MacOS echt super an....

    Naja weiteres poste ich morgen...

    Setzen 5

    Nochmal, eine WPF oder WinForms Anwendung läuft NUR unter Windows. Es gibt bei einem NuGet Paket auch kein "ideal".

    Schau dur das Thema an. Und ich sags gleich, da wirst du nucht innerhalb von 2 Stunden durchblicken.

    Ich glaube du wirst es nicht brauchen, und mit Zukunftssicher hat es auch nicht sooo viel zu tun.

    Grüße
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    kafffee schrieb:

    Andererseits hört sich Kompatibilität mit Linux oder MacOS echt super an....


    Die Bass ist ja für all diese Plattformen vorhanden. Aber was Nofear23m schon sagte, WPF und WinForms sind Windows-Exklusiv. Kannst das zwar mit Mono auf Linux zum laufen kriegen, aber das wäre ja nicht Multi-Plattform im eigentlichen Sinn. Für Mac gäbe es bestimmt auch eine Runtime.

    Wenn du wirklich für mehrere Plattformen entwickeln willst, aber nicht auf .NET / .NET FW verzichten möchtest kannst du eine UWP App machen. Aber UWP gilt bereits als Deprecated, also eine gute Basis für die Zukunft wäre das nicht. Solltest du trotzdem mal für mehrere Plattformen entwickeln wollen, würde ich C++ empfehlen.

    @kafffee

    Zum Thema Abhängigkeiten von Nuget-Pakten: Wenn ich so sehe welche Nuget-Pakete du verwendest, fällt mir nur eines dazu ein. Mach Dich unabhängig davon.

    WindowsAPICodePack: Was genau benötigst Du daraus?

    Sandreas.AudioMetaData: Vermutlich um im allgemeinen Audio-Tags (ID3V1/2) auszulesen und ggf. zu schreiben?

    Bass.dll: Zum abspielen von Audio-Dateien?

    Viele Sachen die es als Nuget-Paket gibt, lassen sich mit etwas Aufwand auch selbst programmieren und dann stellt sich auch nicht die Frage ob das nun unter NetFx, NetCore oder oder laufen soll.

    Wenn es Plattformunabhängig sein soll, da hat MS sich ja wieder ganz was neues einfallen lassen: docs.microsoft.com/en-us/dotnet/maui/what-is-maui
    Mfg -Franky-

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „-Franky-“ ()

    Nofear23m schrieb:

    Nochmal, eine WPF oder WinForms Anwendung läuft NUR unter Windows.


    OK ich habs verstanden :) Hab bloss diesen Artikel hier gelesen, aber nicht auf die Rolle von WPF dabei geachtet...:
    chudovo.de/difference-between-net-core-and-net-framework/

    Ich hab eine Alternative zu Sandreas.AudioMetaData gefunden:
    https://www.nuget.org/packages/z440.atl.core/

    Auf diese baut Sandreas.AudioMetadata nämlich auf.

    Steht dran dass es .NET Framework 4.8 kompatibel ist, somit bräuchte ich bloss von 4.6.1 auf 4.8 upgraden...
    Das geht ja über die Projekteigenschaften, aber werde ich damit weniger Probleme als mit dem Upgrade Assistant haben??

    @-Franky-

    -WindowsAPICodePack brauche ich nur für den FolderPicker. Hab eigentlich auch schon selber einen geschrieben, mich dann aber dagegen entschieden, weil ich wollte dass der User in diesem Fall auf was "Gewohntes" zurückgreifen kann...

    -Sandreas.AudioMetadata: Nicht nur für ID3-Tags, sondern auch für andere gängige Audioformate wie OPUS, FLAC, WMA... Das würde einfach den Rahmen sprengen...

    -bass.dll: Ich will ja nicht nur abspielen sondern auch tausend andere Dinge damit machen, die einfach nicht ohne monatelangen Aufwand selber zu machen sind. Erinner dich z.B. an diesen Thread:
    https://www.vb-paradise.de/index.php/Thread/135276-Externe-und-interne-IP-des-Computers-ermitteln/?postID=1168990&highlight=icecast#post1168990

    Ich will jetzt erstmal, wie NoFear23m passend gesagt hat, das Projekt auf die Strasse bringen.

    Aber: Wo ich es mir vielleicht noch vorstellen könnte, das selbst auszuprogrammieren, wäre eine von diesen Web-APIs, mit der man online Song Lyrics runterladen kann: Entweder OVH oder AZLyrics oder Genius... Da bräuchte ich aber Hilfe...

    -Franky- schrieb:

    Wenn es Plattformunabhängig sein soll, da hat MS sich ja wieder ganz was neues einfallen lassen:

    Ah interessant. Das wäre so ein nächstes Projekt damit anzufangen. Jetzt muss ich aber erstmal mit meinem Player fertig werden...

    kafffee schrieb:

    -Sandreas.AudioMetadata: Nicht nur für ID3-Tags, sondern auch für andere gängige Audioformate wie OPUS, FLAC, WMA... Das würde einfach den Rahmen sprengen...


    Willst du nur lesen oder auch schreiben? Für lesen reicht die BASS aus, das hat die auch drauf.

    Falls nur lesen:
    Schau mal nach dem un4seen.bass.addon.tags namespace.
    bass.radio42.com/help/html/4ee…26a-f62b-6cc9b8744682.htm

    Und hier wie man die ausliest, wie auch welche Tags nutzbar sind.
    bass.radio42.com/help/html/311…fa0-95a4-95fa754510ed.htm

Facebook
Telefonspende