Kein Windows mehr auf ARM

[maniacintosh]

Genau. Und all diese Punkte macht die Konkurrenz. Mal abgesehen davon dass das mitliefern eines Befehlssatzes auf macOS Ebende nicht schwer ist (einfache Existenz von Librarys). Bei allgemein lauffähigen Prozessoren wie z.B. x86, ist dass dann keinerlei problem.
Bei ARM gebe ich dir insofern recht, dass die grundlegende Architektur 64 Bit ist. Allerdings funktioniert bei x86 auch 32 Bit Software auf 64 Bit Hardware. Inwiefern dies vergleichbar ist weiß ich nicht. Aber eigentlich gehe ich nicht davon aus, dass dies bei ARM anders wäre. Sind beides RISC CPU's, die zugrundeliegende Architektur ist also sehr gleich.

Da Apple inzwischen auf den anderen ARM-Plattformen (tvOS, iOS, iPadOS und watchOS) 32bit-Software verbannt hat, wäre ich mir nicht sicher, ob Apple in seinen Chips 32bit-ARM überhaupt noch vollständig implementiert, da dies eigentlich nicht benötigt wird. 64bit-ARM ist ein eigener Befehlssatz und (auch nur eben angelesen) es gibt bei ARMv8 eben zwei Modi. Wenn man ARMv8 vollständig implementiert sollte sowohl 32bit-ARM-Software als auch 64bit-Software ausgeführt werden können. Aber hat Apple vollständig implementiert? Bzw. wird Apple es bei den Mac-Chips tun?

Und es ist ja nicht damit getan einfach weiter die alten 32bit-tauglichen Librarys und APIs unverändert weiter mitzuliefern. Ich muss eben auch weiter darauf achten, dass sie zum Rest des Systems kompatibel bleiben und dafür alles weiter pflegen, anpassen und auch testen. Diesen Aufwand will Apple sich sparen, daher keine 32bit-Software mehr.

In Rosetta 2 spart man sich dadurch z.B. die Legacy Modes der x86-CPUs nachzubilden, man muss eben nur noch den 64bit-Modus nachbilden (wobei auch hier 32bit-Code nicht generell ausgeschlossen wäre, so wie ich es verstehe).

32bit weiter zu unterstützen erhöht die Komplexität der Software. Wenn Apple wollte, hätte man auch Rosetta 1 und die Classic-Umgebung seit Jahren noch weiter mitziehen können, hat man aber auch nicht (auch hier gibt es keine Gründe, die das technisch kategorisch ausschließen würden). Apple hat seit jeher nur für eine gewisse Zeit der Transition Kompatibilität gewährleistet. Microsoft verfolgt hier mit Windows einen anderen Ansatz und bietet sehr lange Software-Kompatibilität, aber auch das hat eben nicht nur Vorteile.

Wurde OpenGL nicht schon vor einigen Jahren komplett rausgeschmissen für Metal? Ist das nicht auch der Grund warum die Adobe Creative Suite wie ein Sack Nüsse läuft? Weil der native GPU-Support über OpenGL fehlt und jetzt auf Metal zurückgegriffen werden muss, was nicht so gut läuft?

Mac-Computer, die OpenCL- und OpenGL-Grafik verwenden - Apple Support (DE)

Unter macOS können Programme OpenCL und OpenGL verwenden, um die Leistung des modernen Grafikprozessors (GPU) des Mac voll auszuschöpfen. Im Folgenden erhältst du weitere Informationen über die OpenGL- und OpenCL-Versionen, die dein Mac unterstützt.

support.apple.com

Laut Apple können sogar Catalina-Only-Macs, wie der Mac Pro OpenGL 4.1.

Ja tun sie, hatten Treiber fertig, Apple hat sich geweigert diese zu signieren.
Und das ganze ist Apples entscheidung! Apple entscheidet keine NVidia Chips zu verbauen. Apple entscheidet dass in externe GPU-Cases keine NVidia Grafikkarten eingebaut werden können, indem sie die Treiber nicht mehr bereit stellen.

Naja, unsigniert hätte man die Treiber ja veröffentlichen können. Genau für so etwas kann man SIP abschalten. Das Apple die Treiber nicht signiert, ist aber in der Tat nicht die feine englische Art.

 

[Martin Wendel]

Genau. Und all diese Punkte macht die Konkurrenz.

Microsoft machts halt umgekehrt. Die emulieren x86 32-bit Code für Windows 10 ARM aber dafür halt keinen 64-bit Code. Welche der beiden Herangehensweisen wohl sinnvoller ist?

 

[Mitglied 241048]

Das was ich an Windows am meisten vermisse ist ein Äquivalent zu Time Machine ...

Hyper Backup auf einer Synology DiskStation wäre z.B. so ein Äquivalent.
Wenn Mac OS X zukünftig auf ARM-Plattformen läuft, dann könnte es ja vielleicht auch auf einem Microsoft Surface Pro X laufen und man hätte endlich mal eine direkte Touch- und Stiftbedienung. Aber auch dazu müsste natürlich Apple Mac OS X für eine Installation auf Dritt-Hardware freigeben.

 

[ottomane]

Aber auch dazu müsste natürlich Apple Mac OS X für eine Installation auf Dritt-Hardware freigeben.

Eher friert die Hölle zu. Zugegebenermaßen wäre das aus Sicht von Apple auch ziemlich dumm.

 

[RainerW]

@hosja

Und Windows kann bis heute 32 Bit Anwendungen starten und verwenden. Im Gegensatz zu Apple welche dies einfach grundlos geblockt haben!

...exakt das ist ein ständiges Ärgernis bei Windows - durch diesen 32bit-Support schafft sich Microsoft viele Probleme und hätte diese "alten" Zöpfe schon längst konsequent abschneiden sollen...

 

[ImpCaligula]

...exakt das ist ein ständiges Ärgernis bei Windows - durch diesen 32bit-Support schafft sich Microsoft viele Probleme und hätte diese "alten" Zöpfe schon längst konsequent abschneiden sollen...

Das sagst Du als Apple User so einfach.

Apple tut sich da einfach leichter. Die Rechner findest Du vor allem bei Privatpersonen, Solo Selbständigen oder gerade mal ein einer Abteilung eines Betriebes, bei dem der Rest 99% Windows Rechner sind.

Was glaubst Du was passieren würde, wenn MS genauso konsequent alte Zöpfe abschneiden würde? Den Aufschrei der Admins (alles was sich ändert was wir seit 20 Jahren so machen ist generell blöd und braucht keiner!) möchte ich nicht erleben. Ernsthaft. Da würde die Hütte bei MS brennen!

Da gibts Betriebe die fahren noch Windows 98 weil kein Bock auf Veränderung da ist.

Apple hat es auch recht einfach alte Zöpfe ab zu schneiden.

Bei MS hängt da viel mehr dann. Milliarden Rechner - Milliarden an Software - Zubehör Hersteller - aber Milliarden Treiber..... das ist nicht so einfach. Das muss man MS einfach zugestehen.

 

[RainerW]

Das sagst Du als Apple User so einfach.

Apple tut sich da einfach leichter. Die Rechner findest Du vor allem bei Privatpersonen, Solo Selbständigen oder gerade mal ein einer Abteilung eines Betriebes, bei dem der Rest 99% Windows Rechner sind.

Was glaubst Du was passieren würde, wenn MS genauso konsequent alte Zöpfe abschneiden würde? Den Aufschrei der Admins (alles was sich ändert was wir seit 20 Jahren so machen ist generell blöd und braucht keiner!) möchte ich nicht erleben. Ernsthaft. Da würde die Hütte bei MS brennen!

Da gibts Betriebe die fahren noch Windows 98 weil kein Bock auf Veränderung da ist.

Apple hat es auch recht einfach alte Zöpfe ab zu schneiden.

Bei MS hängt da viel mehr dann. Milliarden Rechner - Milliarden an Software - Zubehör Hersteller - aber Milliarden Treiber..... das ist nicht so einfach. Das muss man MS einfach zugestehen.

...nein, das sage ich nicht so leicht als Apple User, denn ich nutze Apple nur privat - beruflich habe ich in der IT zu 100% mit Microsoft zu tun.

 

[Scotch]

Gerade im Musikbereich habe ich immer wieder das Gefühl, (...)

Apple hat nach Leopard mit schöner Regelmässigkeit sein Treibermodell all paar Releases auf Links gedreht. Da es für macOS aber nicht viele Geräte gibt, die nicht class compliant sind (weil es im Vergleich zur PC-Welt halt ziemlich wenig Peripherie gibt), fällt das natürlich nur da auf, wo plötzlich was nicht mehr funktioniert. Und das sind unter macOS halt bevorzugt Audio-Klamotten - der ganze Rest hatte die gleichen Probleme, aber das waren halt eher exotische Anwendungen (z.B. zahlreiche Dia- und Filmscanner - genau wie später mit Aperture hat halt Apple irgendwann beschlossen "Foto interessiert uns nicht mehr"). Aber die ganzen Highend-Audio-I/f liefen halt erst mal nicht mehr - und das sind mit ihren ultrakurzen Latenzen ganz sicher nicht die Firmen, die irgendwelche Deppen für die Treiberentwicklung anstellen.

vorbei an allen Spezifikationen - selbst programmieren wollen, weil das "besser sei".

Nun ja, genau wie bei Grafiktreibern ist halt bei HW-Treibern "bare metal programming" angesagt. Die Schnittstelle von Apple heisst ja auch nicht aus lauter Langweile so. Um das mal mit Zahlen zu verzieren: Mein mittlerweile 12 Jahre altes USB-Audio-I/F (2-Kanäle, Mackie-Preamps, HW-Monitoring) kam damals mit Treibern für den Mac. Irgendwann gab's keine Updates mehr, siehe oben. Das war nicht so schlimm, denn das I/F ist class compliant, tat's halt einfach weiter. Prima, oder? Dann mal Zahlen: Unter macOS erreicht das Interface passable 12ms Latenz. Das ist für die Preisklasse und das Alter OK. Unter Windows läuft das I/F mit dedizierten (12 Jahre alten) Treibern, die mal für XP oder Vista entwickelt wurden. Natürlich werden neuer Features des OS (z.B. Integration in den Systemmixer) nicht mehr unterstützt - aber der Treiber läuft. In Zahlen: Unter Windows habe ich 4ms Latenz - und das ist tiptop. Soll heissen: Meine Investition performt unter Windows 10 wie am ersten Tag - unter macOS funktioniert's noch, aber mit angezogener Handbremse. Und viele andere (auch teure) Hardware hatte nicht so viel Glück. Auch mein DiMage III Scanner tut's unter Windows 10 wie am ersten Tag. Treiber - kein Problem (der ist nicht Class-Compliant). Unter OS X ist seit Lion Schluss...

Wie gesagt: Gerade in dem Bereich fällt das doch immer wieder auf.

Das würde dir auch in vielen anderen Bereichen auffallen - da gibt es nur schlicht und einfach inzwischen gar keine HW mehr, die das betreffen könnte, da sich auf Grund von Apples Willkür die Hersteller seit vielen Jahren zurückgezogen haben. Im Audio-Bereich gibt's da halt noch Geschäft - und damit die Probleme. Die gleiche HW läuft ja nun auch unter Windows und funktioniert ohne Probleme nach einem OS Update weiter. Weil eben nicht ständig und andauernd Treiberarchitekturen geändert werden. Stellt sich also die Frage: Warum macht Apple das? Ich habe keine Ahnung - aber wirklich notwendig scheint das nicht zu sein, denn die HW läuft ja unter Windows beileibe nicht schlechter, siehe oben.

Laut Apple können sogar Catalina-Only-Macs, wie der Mac Pro OpenGL 4.1.

Ja eben: Die Version ist 10 Jahre alt

Hyper Backup auf einer Synology DiskStation wäre z.B. so ein Äquivalent.

Hyper Backup sichert dein NAS, aber doch keine Clients?! Wie soll das denn eine Alternative zu TM sein?

 

[Mitglied 241048]

Hyper Backup sichert dein NAS, aber doch keine Clients?! Wie soll das denn eine Alternative zu TM sein?

Indem du z.B. deine Clients mit volume 0 des NAS per Synology Drive synchronisierst und dann volume 0 per Hyper Backup auf volume 1 sicherst. Mache ich seit Jahren so und funktioniert hervorragend.

 

[Scotch]

Damit hast du immer noch keinen TM-Ersatz für deine Clients (sondern für dein NAS) und der Drive Client ist leider auch keine Alternative, da er zwar sehr zuverlässig sichert und synchronisiert, auch mit mehreren Dateigenerationen, aber funktional dermassen eingeschränkt ist, dass man ihn nicht auf das ganze System, sondern nur einzelne Ordner loslassen kann, da er einem ansonsten in kürzester Zeit jedes Backup-Volume zumüllt.

 

[hosja]

Neuste Version von VS Code wurde jetzt auch für Windows in ARM releast. Da MS hart in die Cloud rennt denke ich .Net Core und VS Code sind für MS die Developertools der Zukunft.

 

[ImpCaligula]

Neuste Version von VS Code wurde jetzt auch für Windows in ARM releast. Da MS hart in die Cloud rennt denke ich .Net Core und VS Code sind für MS die Developertools der Zukunft.

Hast Du Dir mal VS Code angeschaut? Du bringst jetzt schon zum zweiten mal VS Code und .Net in einen Topf.

VS Code hat mit Visual Studio & Net soviel zusammen zu tun, wie ein Stück Papier und ein schwarzes Loch - gar nichts. VS Code ist ein simpler Code Text Editor für alle möglichen Script Sprachen. Visual Studio und das Net Framework haben damit nicht mal ansatzweise was damit zu tun. Und nein - das Net Framework wird unter macOS bis heute Stiefmütterlich behandelt und tut sich auch nichts Neues - und unter ARM für Mac noch nicht mal Überlegungen da.

 

[ottomane]

Ich war auch schon ganz verwirrt. Danke.

 

[Scotch]

denke ich .Net Core und VS Code sind für MS die Developertools der Zukunft

Das ist ja mal eine ganz neue Erkenntnis.

VS Code ist ein simpler Code Text Editor für alle möglichen Script Sprachen.

Vielleicht guckst du dir mal VS Code in Ruhe an. Wenn VS Code ein "simpler" Texteditor ist, dann ist Xcode ein Tamagotchi für Programmierer.

Visual Studio und das Net Framework haben damit nicht mal ansatzweise was damit zu tun.

Das hat er auch nicht behauptet. Du musst mal lesen, was geschrieben wird, kein Mensch redet von VS. Ansonsten ist VS Code z.B. unter Linux die einzig' sinnvolle IDE für .NET Core, also so völlig "entkoppelt" ist das nicht. Es sei denn, man betrachtet Xcode auch nicht als unbedingt nötig, um mit Cocoa oder SwitftUI zu entwickeln. Geht ja auch z.B. mit VS Code.

das Net Framework wird unter macOS bis heute Stiefmütterlich behandelt

Was meinst du damit, die Versionen von .NET Core unter Windows und macOS sind doch auf dem gleichen Stand? .NET für macOS wäre sinnfrei. Es kommt ja auch keiner auf die Idee, Cocoa für Windows umzusetzen - ganz im Gegensatz zu ".NET Core"-Funktionalität aus der L/Unix Welt. Dafür gibt's dann halt die POSIX-APIs und WSL.

Ich war auch schon ganz verwirrt.

Ich bin ehrlich gesagt von euren Einlassungen verwirrt - hab' ich was nicht verstanden?

 

[ImpCaligula]

Vielleicht guckst du dir mal VS Code in Ruhe an. Wenn VS Code ein "simpler" Texteditor ist, dann ist Xcode ein Tamagotchi für Programmierer.

Es ist ein TextEditor mit einem sehr guten Funktionsumfang - er hat aber keine direkte .Net Integration wie zum Beispiel die Visual Studio IDE. Microsoft selbst schreibt für VS Code - "Visual Studio Code ist ein freier Quelltext-Editor von Microsoft."

Das hat er auch nicht behauptet. Du musst mal lesen, was geschrieben wird, kein Mensch redet von VS. Ansonsten ist VS Code z.B. unter Linux die einzig' sinnvolle IDE für .NET Core, also so völlig "entkoppelt" ist das nicht. Es sei denn, man betrachtet Xcode auch nicht als unbedingt nötig, um mit Cocoa oder SwitftUI zu entwickeln. Geht ja auch z.B. mit VS Code.

Ja so gesehen kann ich jeden 0815 Text Editor um auf die .Net Bibliothek zurück zu greifen. Er vermischt aber die Visual Studio IDE mit .Net und Visual Code und UWP Apps und was weiß ich nicht noch alles.

Vielleicht solltest Du nicht nur dieses eines Posting betrachten zu dem Thema - sondern auch die vorherigen - meine Reaktion bezieht sich auf alle seine Postings zu dem Thema.

Und das lautet in etwa so zusammengefasst - keine Angst vor ARM - Microsoft geht mit VS Code und der Net Bibliothek eh den Weg Richtung UWP Apps (die MS dummerweise für tot erklärt hat - aber he wen interessiert es) und dann müsse man mit ARM auf Mac keine Angst mehr vor der Zukunft haben.

Was meinst du damit, die Versionen von .NET Core unter Windows und macOS sind doch auf dem gleichen Stand?

.Net Core reicht aber oft nicht für eine 1:1 Plattformunabhängige Entwicklung. Schon gar nicht, wenn es Richtung GUI Anwendung geht.

Aber wie gesagt - schau Dir seine letzten Postings zu dem Thema an - dann verstehst den Zusammenhang meiner Antwort.

 

[ottomane]

Ich bin ehrlich gesagt von euren Einlassungen verwirrt

Naja, dass CS Code ein *simpler* Texteditor ist, ist sicher nicht ganz treffend, aber letztlich ist es ein Editor. Selbst Microsoft schreibt das: "Visual Studio Code is a lightweight but powerful source code editor". Dem wollte ich zustimmen, zusammen mit der Aussage, dass das erst einmal nicht direkt was mit .NET Core zu tun hat.

 

[ImpCaligula]

Naja, dass CS Code ein *simpler* Texteditor ist, ist sicher nicht ganz treffend, aber letztlich ist es ein Editor. Selbst Microsoft schreibt das: "Visual Studio Code is a lightweight but powerful source code editor". Dem wollte ich zustimmen, zusammen mit der Aussage, dass das erst einmal nicht direkt was mit .NET Core zu tun hat.

Eben - VS Code ist erst mal ein Texteditor (mit einem sau guten Funktionsumfang und sehr gut umgesetzt) aber er ist ein TextEditor unter vielen und hat direkt mit .Net Core nichts zu tun. VS Code kann ich jederzeit für so ziemliche jede Sprache verwenden und nutzen.

Visual Studio IDE hat da zu .Net eine ganz anderen Bezug.

Natürlich kann ich .Net Core ud VS Code verwenden - ich könnte aber auch .Net Core mit anderen Editoren verwenden. Daher ist ein direkter Zusammenhang nicht gegeben. Anders wie bei der großen Visual Studio .Net IDE.

 

[Scotch]

er hat aber keine direkte .Net Integration wie zum Beispiel die Visual Studio IDE.

Was meinst du mit ".NET Integration"? IntelliSense? Klassenbrowser? Targets des SDK? Gibt's doch auch alles in VS Code...? Musst halt die .NET Extensions installieren, wenn du VS Code dafür benutzen willst. Das soll nicht heissen, dass das "besser" als VS ist (außer auf dem Mac, da ist VS grauslig - nur meine persönliche Meinung ). Ich versteh' nur die grundsätzliche Abgrenzung, die du da machst nicht wirklich.

Schon gar nicht, wenn es Richtung GUI Anwendung geht.

Wie gesagt: Plattformunabhängige GUIs benötigen auch plattformunabhängige Frameworks. Das sind weder .NET, noch Cocoa. Daher macht weder .NET unter macOS, noch Cocoa unter Windows Sinn. Es gibt ja Gründe für den Erfolg von Node.js, Angular Cordova, Ionic, Xamarin, Unity...

Selbst Microsoft schreibt das (...)

Die müssen ja auch irgendwie VS Code und VS voneinander abgrenzen Ich hab' hier beides am Start - natürlich ist VS die nützlichere Umgebung für .NET Entwicklung, allein schon weil es tools gibt, die eben nur in VS so schön integriert sind. Könntest du mir aber jetzt so spontan sagen, was in VS wirklich "besser" geht, als in VS Code? Benutzt du beide Tools?

Dem wollte ich zustimmen, zusammen mit der Aussage, dass das erst einmal nicht direkt was mit .NET Core zu tun hat.

Dann muss man konsequent aber auch sagen, dass VS erst mal nichts direkt mit .NET (Core) zu tun hat. Zumal man auf keinen Fall .NET und .NET Core verwechseln sollte. Wenn du keine C# Unterstützung und ein .NET SDK installierst, sondern z.B. die R Unterstützung (oder auch die Python Unterstützung, wenn R zu "exotisch" ist), dann hat auch VS "nichts mit .NET zu tun".

Visual Studio IDE hat da zu .Net eine ganz anderen Bezug.

Siehe oben - ich hab' irgendwie das Gefühl, wir reden hier von verschiedenen Tools. Oder ihr habt beide noch nicht so wirklich in echt benutzt...?!

Nur der Vollständigkeit halber: Auch MS bewirbt VS nicht als ".NET IDE", bzw. nicht mehr als "F# IDE", "Azure IDE" (um auch ein Beispiel ohne .NET zu bringen) usw. Das ist - genau wie bei VS Code - ein möglicher Einsatz unter Vielen.

Wie gesagt, ich verstehe die Grundsatzdiskussion nicht. Ist aber inzwischen ein bisschen sehr OT

 

[ImpCaligula]

Was meinst du mit ".NET Integration"? IntelliSense? Klassenbrowser? Targets des SDK? Gibt's doch auch alles in VS Code...? Musst halt die .NET Extensions installieren, wenn du VS Code dafür benutzen willst. Das soll nicht heissen, dass das "besser" als VS ist (außer auf dem Mac, da ist VS grauslig - nur meine persönliche Meinung ). Ich versteh' nur die grundsätzliche Abgrenzung, die du da machst nicht wirklich.

Siehe oben - ich hab' irgendwie das Gefühl, wir reden hier von verschiedenen Tools. Oder ihr habt beide noch nicht so wirklich in echt benutzt...?!

Dann zeig mir doch mal wie Du .Net Office PlugIns unter Visual Code entwickelst samt Ribbon Editor und geöffneter Excel (Word, PP...) wie in Visual Studio... zeig mir das mal mit dem TextEditor Visual Code .... mache Dir gerne einen Screenshot mit meinem Visual Studio und dann zeigst mir wie Du das hinbekommst in "Deinem" TextEditor...

Oder den Visual Studio Klassendesigner... oder... die visuelle Android App Entwicklung unter Visual Studio oder.... also das machst Du alles auch in Visual Code....von den ganzen Team Tool in Visual Studio mal abgesehen. Also zwischen Visual Studio und dem Visual Code ist doch noch ein himmelweiter unterschied? Bin ich gespannt lieber Scotch...

 

[Scotch]

Meine Güte, auf welchem Kreuzzug bist du denn? Keiner will VS schlecht machen

Dann zeig mir doch mal wie Du .Net Office PlugIns unter Visual Code entwickelst samt Ribbon Editor und geöffneter Excel (Word, PP...) wie in Visual Studio...

Ich weiss nicht genau, wie wir jetzt von .NET auf Office Plug-Ins kommen, aber das geht in VS Code mit Yeoman. Den grafischen "Multifunktionsleisten-Editor" gibt's glaube ich nur in VS. Was das mit "geöffneter Excel, Word, PP..." bedeutet, verstehe ich nicht. Was hat das mit VS oder VSC zu tun? Oder geht's um Debuggen einer laufenden Erweiterung? Das geht mit der entsprechenden Extension ("MS Office Add-In Debugger").

Oder den Visual Studio Klassendesigner...

Ob man den benutzen will, könnte man abendfüllen diskutieren (ich benutze EA), aber da gibt's verschiedene für VSC, z.B. yUML, Mermaid...

die visuelle Android App Entwicklung unter Visual Studio oder

Jetzt sind wir aber meilenweit von .NET weg und VS als die Traum-IDE für Android App zu positionieren, dürfte nicht mehrheitsfähig sein Wie gesagt: Das sind alles eierlegende Wollmilchsäue, man kann auch Mac Apps auf einem Mac mit VS erstellen. Wenn man das denn möchte. Ich nehm' da trotzdem lieber Xcode (für Swift) und VSC (für alles andere).

von den ganzen Team Tool in Visual Studio mal abgesehen

Wenn man die Team Services nutzt, geht tatsächlich (fast) kein Weg an VS vorbei. Aber das hat dann gar nichts mehr mit .NET zu tun, sondern ist der Tatsache geschuldet, dass es praktisch keine Frontends für MS proprietäres Repo gibt. In Anbetracht der Tatsache, dass MS Github gekauft hat, dürfte das aber auch ein Auslaufmodell sein. Ich persönlich kenne aber auch niemanden, der die Team Services benutzt, deshalb hab' ich das auch nicht auf dem Schirm.

Also zwischen Visual Studio und dem Visual Code ist doch noch ein himmelweiter unterschied?

Es hat niemand behauptet, dass das die gleichen Programme (bzw. Programmsammlungen) sind. Ich habe einzig und allein nachgefragt, warum du solche Grundsatzdiskussionen bzgl. VS und VSC im Bezug auf .NET führst. Das ist wenig überraschend einer der Bereiche, wo die Unterstützung auch in VSC mit am besten ausgebaut ist. Wenn du dir deinen letzten Beitrag durchliest, wirst du vielleicht auch mit etwas Abstand feststellen, dass deine Argumente auch i.W. gar nichts mehr mit .NET zu tun haben.

Wenn du VS besser findest als VSC - ist doch OK. Ich benutze es auch, u.a. weil z.B. die Tools des RDS in VS perfekt integriert sind und es praktisch keine Integration für VSC gibt. Wenn ich aber OpenCV benutze, sieht das schon wieder anders aus.

Und damit (und weil zu viel OT): Einen entspannten Abend mit dem Tool deiner Wahl. Bei mir ist das übrigens gerade RStudio, weil mich das fehlende CLI-Fenster in VS und und der kaputte Paketmanager in VSC nerven