Herangehensweise Entwicklung von Crossplatform-Anwendung

  • .NET MAUI

Es gibt 25 Antworten in diesem Thema. Der letzte Beitrag () ist von siycah.

    tragl schrieb:

    jetzt wurde eine ganze Latte an Zeug nachinstalliert

    Dann ist zumindest der Grund, warum das nicht funktioniert hat, klar. Du hattest schlicht die Dependencies nicht installiert - kann passieren.

    tragl schrieb:

    VisualStudio

    Ab in die Tonne damit. Ist abgekündigt.

    tragl schrieb:

    VisualCode meldet, dass er XCode nicht finden kann

    Du bist dir sicher, dass du XCode installiert hast?
    Nicht nur die Command-Line Tools, sondern wirklich XCode. Die CLTools brauchst du nur für C/++ Entwicklung und das bauen von Paketen. Für die ganzen macOS/iOS-spezifischen Sachen brauchst du XCode. Gibt's im AppStore.

    tragl schrieb:

    Ist schon echt nervig das Ganze.

    Es ist auf dem Mac anstrengender als auf Linux und Windows, ja das stimmt. Aber hat man's einmal, läuft das Ganze. Ich würde nur die Finger von XCode selbst lassen. Das ist die grottigste IDE, die es gibt. Da nehme ich lieber Eclipse.

    tragl schrieb:

    Welche Reihenfolge müsste ich hier beachten?


    XCode -> dotnet -> je nach Projekt weitere Dependencies
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems

    Selbstständiger Softwareentwickler & IT-Techniker.
    @siycah:
    Ja, ich habe XCode installiert:



    Den Rest hab ich auch nach deiner Anleitung gemacht. VisualStudio war ein Versuch von mir, ob's ggf. damit klappt.
    -Also ich hab erst Brew installiert (bzw. war schon, der Pfad wurde nur nicht gespeichert)
    -danach "dotnet installieren" nach deiner verlinkten Anleitung
    -VisualStudio Code
    -und eben dann noch den workload-install von maui, laut deiner Anleitung

    Fazit:
    Es funktioniert leider nicht. Ich hätte das gerne am Laufen und für mich persönlich wär's auch schon, wenn ich dann mit VSCode zurecht komme,
    wobei ich für den Anfang auch finde, das VS2022 erstmal egal ist, denn es ist eine gewohnte Umgebung für mich.

    Ich weiß aber absolut nicht, was ich noch machen soll.
    Achso, ggf. ist es wichtig zu erwähnen dass ich AndroidStudio drauf habe, um 1-2 Apps zu testen - ich möchte nicht noch ein Android-Tablet mit
    mir rum schleppen, wenn ich unterwegs bin. Ist für mich der bequemere Weg (blueStacks läuft nicht auf den M-Prozessoren) und außerdem mag ich
    Android nicht :P
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    tragl schrieb:

    Ich hätte das gerne am Laufen und für mich persönlich wär's auch schon, wenn ich dann mit VSCode zurecht komme,
    wobei ich für den Anfang auch finde, das VS2022 erstmal egal ist, denn es ist eine gewohnte Umgebung für mich.


    Ich hätte allerdings auch gerne, dass es bei dir läuft. Ich kann das aktuell so gar nicht nachvollziehen, dass das bei dir so am zicken ist.
    Das hat alles auf Anhieb bei mir funktioniert.

    Also mal so zum Verständnis:

    Brainfuck-Quellcode

    1. simon@ODIN: /home/simon/source/Hermod git:(feat/alpha-branch) ✗
    2. ➜ uname -a && dotnet --list-sdks
    3. Linux ODIN 5.15.146.1-microsoft-standard-WSL2 #1 SMP Thu Jan 11 04:09:03 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
    4. 7.0.115 [/usr/lib/dotnet/sdk]
    5. 8.0.101 [/usr/lib/dotnet/sdk]
    6. simoncahill@Frigg: /Users/simoncahill
    7. ➜ uname -a && dotnet --list-sdks
    8. Darwin Frigg.fritz.box 23.4.0 Darwin Kernel Version 23.4.0: Sat Jan 27 14:26:10 PST 2024; root:xnu-10063.100.633~14/RELEASE_ARM64_T6000 arm64
    9. 6.0.404 [/usr/local/share/dotnet/sdk]
    10. 6.0.405 [/usr/local/share/dotnet/sdk]
    11. 6.0.406 [/usr/local/share/dotnet/sdk]
    12. 6.0.408 [/usr/local/share/dotnet/sdk]
    13. 6.0.413 [/usr/local/share/dotnet/sdk]
    14. 6.0.419 [/usr/local/share/dotnet/sdk]
    15. 7.0.101 [/usr/local/share/dotnet/sdk]
    16. 7.0.102 [/usr/local/share/dotnet/sdk]
    17. 7.0.103 [/usr/local/share/dotnet/sdk]
    18. 7.0.200 [/usr/local/share/dotnet/sdk]
    19. 7.0.201 [/usr/local/share/dotnet/sdk]
    20. 7.0.203 [/usr/local/share/dotnet/sdk]
    21. 7.0.307 [/usr/local/share/dotnet/sdk]
    22. 7.0.313 [/usr/local/share/dotnet/sdk]
    23. 8.0.100-rc.1.23463.5 [/usr/local/share/dotnet/sdk]
    24. 8.0.201 [/usr/local/share/dotnet/sdk]
    25. Platform ServicePack Version VersionString
    26. -------- ----------- ------- -------------
    27. Win32NT 10.0.22635.0 Microsoft Windows NT 10.0.22635.0
    28. 8.0.101 [C:\Program Files\dotnet\sdk]
    29. 8.0.102 [C:\Program Files\dotnet\sdk]


    Ich habe das auf drei komplett unterschiedlichen Plattformen gleichzeitig laufen.
    Windows, Linux (auch Linux aarch64) und macOS (aarch64) laufen.
    Nebenher laufen noch zahlreiche C++-Umgebungen, Rust und noch vieles Weitere.

    Ich bin gerade echt ein wenig baff, dass das bei dir so zickt.

    tragl schrieb:

    außerdem mag ich
    Android nicht

    So verschieden können Leute sein. Ich kann iOS auf den Tod nicht ab :D
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems

    Selbstständiger Softwareentwickler & IT-Techniker.
    Die Ausgabe sieht ja erstmal ähnlich aus:


    ist sicherlich nur eine Kleinigkeit, warum das nicht funzt - wie immer.
    Ich kann ggf. anbieten, dass wir die Tage (falls du Lust hast) uns in nem kurzen Call zusammensetzen und schauen uns das zusammen an?

    LG
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:
    Ergebnis vom Telefonat:

    VisualStudio for Mac unterstützt (scheinbar) dotnet 8 nicht und findet dort keine SDKs zum bauen.

    Grundsätzlich hat das Setup funktioniert, es musste nichts neu installiert werden.
    Die Umstellung im Projekt von dotnet 7 auf dotnet 8 und das Entfernen von nicht benötigten Dependencies (die teils auch schlicht nicht vorhanden waren) und die Erkenntnis, dass es ein Bug gibt, der das Zusammenspiel zwischen dotnet/VS Code und XCode bzgl. iOS-Entwicklung behindert haben dafür gesorgt, dass die Umgebung vollumfänglich funktioniert und der Kollege endlich entwickeln kann.
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems

    Selbstständiger Softwareentwickler & IT-Techniker.