News Visual Studio 2022 und .NET 6: Microsoft veröffentlicht seine Werkzeuge für Entwickler

Endlich ein neues Spielzeug.
Ich muss mich aber noch etwas an das noch dunklere Design gewöhnen.

Leider wird AvaloniaUI noch nicht ganz unterstützt, mal gucken wie lange das dauert, dann steige ich auch komplett um.
 
Artikel-Update: Visual Studio 2022 17.1 Preview 1 wurde freigegeben
Im Rahmen der Veröffentlichung von Visual Studio 2022 17.0 hat Microsoft auch bereits die erste Vorschau auf Visual Studio 2022 17.1 zum Download freigegeben. Weitere Informationen liefern die offizielle Release Notes.

Visual Studio 2022 17.1 Preview 1 – Release Notes schrieb:
Debugging & Diagnostics
  • Added a support for Microsoft Azure App Services Attach to Process.
Git Tooling
  • Added capability to include README file when creatting new Git repositories in Visual Studio
  • Enhanced the ability to pin commonly used branches utilizing hover buttons
  • Built a more discoverable UI for relating Work Items with new commits
.NET Multi-platform App UI (MAUI) Preview 10
  • .NET MAUI Preview 10 is now available.
.NET Productivity
  • Go To Definition from source information in PDBs.
  • IntelliSense completion for await within an awaitable expression.
  • Move static members to a new type refactoring.
  • Simplify code to use the new C# 10.0 extended property patterns refactoring.
  • Detect variable swaps and suggest using a tuple to swap values refactoring.
  • Code definition window support for C# and Visual Basic.
  • Enable nullable reference types across a project refactoring.
  • Signature help simplified view improvements when a tuple appears many times within a signature.
  • Understand errors and warnings at a glance with inline diagnostics.
XAML Hot Reload
  • XAML Hot Reload now supports more end-to-end scenarios when using together with .NET Hot Reload.
XAML Live Preview
  • XAML Live Preview now supports .NET MAUI apps (WinUI & Android).

Auch Visual Studio 2022 17.1 Preview 1 kann wie gewohnt direkt unterhalb dieser Meldung aus dem Download-Bereich von ComputerBase heruntergeladen werden.
 
Dark Soul schrieb:
@freek0055 Wie ist dies aufgefallen? Oder welche Limitierungen hast du dadurch gehabt? Habe mich nämlich selbst auch mehrmals gefragt weshalb wir da immer noch bei 32bit sind - aber hatte nie Probleme, somit war es mir egal.
Ich hatte schon Solutions die so groß waren dass VS einfach abgeschmiert ist wenn du versucht hast diese darin zu öffnen. Da wurde dann nur noch mit JetBrains Rider gearbeitet...
Ist natürlich auch nicht sinnvoll so große Solutions entstehen zu lassen, aber zwischen Realität bzw. Ist-Situation und sinnvollem Zielzustand ist oft eben ein großer Gap.
 
Fonce schrieb:
Du nachgedacht habe ich darüber schon viel, nur ist das halt immer eine Frage wieviel Zeit man zur Verfügung hat.
Haha habe genau das Selbe gedacht, so gross sollte eine Solution gar nie werden. Aber ja klar - aint nobody got time for that. Und dann ist das Ganze mal Legacy und man fängt von vorne an :D
Das Management spricht dann von MicroServices als Lösung :freak: Dabei wäre ein gröberes Refactoring auch mal okay gewesen :)

7hyrael schrieb:
Ich hatte schon Solutions die so groß waren dass VS einfach abgeschmiert ist wenn du versucht hast diese darin zu öffnen. Da wurde dann nur noch mit JetBrains Rider gearbeitet...
Haha oh wow, finde ich noch interessant, dass VS die Solution speichern konnte, welche sie im nächsten Schritt nicht wieder öffnen kann:daumen:
 
Ko3nich schrieb:
Gibt es eine Übersicht wie sich die verschiedenen Editionen unterscheiden?
Da sich das bestimmt einige fragen, aber sich vermutlich nicht jeder traut die Frage auch zu stellen, ist der von @DocWindows und @icywiener gepostete Link nun auch im Download-Artikel. Danke für die Anregung.
 
  • Gefällt mir
Reaktionen: N3utr4l1s4t0r und Ko3nich
der News schrieb:
Auch die zum Ausführen von in .NET programmierten Anwendungen zwingend erforderliche Microsoft .NET Desktop Runtime 6.0.0 kann direkt aus dem Download-Bereich von ComputerBase heruntergeladen werden.
Na, so zwingend ist das nicht, das hängt von der App ab.

Ich habe keine Ahnung davon, ich hatte nur über das Changelog von "Paint.NET v4.3" davon erfahren:
https://www.getpaint.net/roadmap.html schrieb:
New: .NET no longer needs to be installed on the system because the app now uses self-contained deployment.

Wenn man dem Link vom Changelog folgt:
https://docs.microsoft.com/en-us/dotnet/core/deploying/ schrieb:
Produce an executable

Executables aren't cross-platform. They're specific to an operating system and CPU architecture. When publishing your app and creating an executable, you can publish the app as self-contained or framework-dependent. Publishing an app as self-contained includes the .NET runtime with the app, and users of the app don't have to worry about installing .NET before running the app. Apps published as framework-dependent don't include the .NET runtime and libraries; only the app and 3rd-party dependencies are included.
 
@Dark Soul
Naja, ist halt ein über 20 Jahre altes Produkt und ich bin erst seit 2 Jahren dabei. Wenn nebenher auch neue Features rein sollen, dauert das halt. Man kann ja schlecht sagen „Wir müssen jetzt erstmal zwei Jahre umbauen und dann haben wir das gleiche Featureset, aber dann gibts wieder neue Features, versprochen…“
 
Fonce schrieb:
Naja, ist halt ein über 20 Jahre altes Produkt und ich bin erst seit 2 Jahren dabei. Wenn nebenher auch neue Features rein sollen, dauert das halt. Man kann ja schlecht sagen „Wir müssen jetzt erstmal zwei Jahre umbauen und dann haben wir das gleiche Featureset, aber dann gibts wieder neue Features, versprochen…“
Ja. Das stimmt. Das kann aber auch schlicht bedeuten das etwas grundsätzlich schief läuft.
Wenn das Feature-Set so umfangreich ist, das man Jahrzehnte braucht das aufzubauen dann ist es ja vielleicht auch ein Zeichen dafür, das es zu umfangreich und zu komplex ist. Das man auch Sachen drin hat, die man gar nicht mehr braucht oder anders lösen kann.

So ist ja auch Visual Studio Code gestartet. Da hat man sich ja bewusst dafür entschieden es eben nicht zu einem zweiten Visual Studio zu machen, sondern tatsächlich ein altlastfreien Neustart hinzulegen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Autokiller677
Kann mir einer sagen wie gut das neue VS mit Python umgehen kann? (Einfache kleine ML Programme)
 
Departet schrieb:
Leider ist .NET MAUI auf 2022 verschoben worden. Mal sehen was die neuen Version sonst so kann.
Auf der Preview ist es ja vorhanden. Lohnt sich das denn überhaupt (für kleine Projekte, kein unternehmensrelevanter Einsatz)?
 
SourceCoder schrieb:
Kann mir einer sagen wie gut das neue VS mit Python umgehen kann? (Einfache kleine ML Programme)
Die Frage erledigt sich doch schon fast in sich selbst. Wenn es nur um kleine, einfache Programme geht, lohnt ganz sicher keine umfangreiche IDE vom Kaliber Visual Studio.
Es sei denn, wir haben eine diametrial unterschiedliche Vorstellung darüber, was kleine, einfache Programme sind.

Abgesehen davon würde ich Python eher bei Visual Studio Code verorten:
https://code.visualstudio.com/docs/languages/python
wenngleich es natürlich da auch was für Visual Studio gibt:
https://visualstudio.microsoft.com/de/vs/features/python/

Aber vielleicht solltest Du einfach mal sagen, welche Funktionalität Du Dir denn konkret von der IDE erwartest. Dann kann man auch viel besser brauchbare Hinweise liefern.
 
daivdon schrieb:
Auf der Preview ist es ja vorhanden. Lohnt sich das denn überhaupt (für kleine Projekte, kein unternehmensrelevanter Einsatz)?

Kann ich dir leider nicht sagen. Wir sind auch nur ein kleines Unternehmen und programmieren eher kleinere Sachen, da wir alle FiSis sind. .net MAUI klingt aber erstmal ganz nett.
 
andy_m4 schrieb:
64 Bit und Hot-Code-Reload. Wow.
Microsoft kommt da an, wo andere gefühlt schon vor 20 Jahren waren. :-)
Apropos.. Die VB6 Community wünscht sich auch seit fast 20 Jahren 64-Bit Support.
Leider hat MS bis heute nichts geliefert bzw. es gab nie ein Update für VB Classic. 😔

Daher gab es immer mal wieder unabhängige Versuche, eine Alternative zu etablieren, so wie zuletzt vor 6 Monaten.
https://www.itmagazine.ch/artikel/74622/Visual_Basic_6_wird_wiederbelebt.html

Immerhin wird VB6 bzw. seine Core-Runtime noch für weitere 10 Jahre unterstützt.
Scheinbar ist es also immer noch von Wert.

https://docs.microsoft.com/en-us/pr.../visual-basic-6/visual-basic-6-support-policy

VB6 basierte auf Visual Studio 6, welche viele Fans noch immer für die beste RAD IDE halten.
Der VB6 Compiler war im Prinzip ein modifizierter VS C++ Compiler.
 
Enurian schrieb:
Nur die default Font sagt mir gar nicht zu, bin da direkt wieder zurück von der aus VS 2019.
du meinst "Cascadia Mono"? Versuch doch mal "Fira Code" in einer ihrer Inkarnationen:, das kann sogar ein paar Ligaturen in VS 2022 (==, !=, >=, <=, allerdings nicht ->)

Was mich sehr hart trifft bei VS 2022: das Theme "Tan" fehlt und ist nicht aufzutreiben. VS und "Tan"-Theme ist (seit gefühlt 20 Jahren) bei mir im Gehirn nebeneinander verdrahtet, hmmm :confused_alt:
 
Zuletzt bearbeitet:
Eine Frage, was ist der einfachste/sicherste Weg, die ganzen NuGet-Packages, die ich in VS2019 installiert habe, zu übernehmen?
 
blöderidiot schrieb:
du meinst "Cascadia Mono"? Versuch doch mal "Fira Code" in einer ihrer Inkarnationen:, das kann sogar ein paar Ligaturen in VS 2022 (==, !=, >=, <=, allerdings nicht ->)
Ja genau. Danke für den Tipp, aber mit Consolas (default in 2019) bin ich sehr zufrieden :)
Die Ligaturen habe ich mir angesehen - fancy, aber ich glaube das würde mich eher verwirren :D

Matutin schrieb:
Eine Frage, was ist der einfachste/sicherste Weg, die ganzen NuGet-Packages, die ich in VS2019 installiert habe, zu übernehmen?
Vielleicht stehe ich auf dem Schlauch, aber die Packages hängen doch am jeweiligen Projekt und werden automatisch geladen, völlig unabhängig davon welche IDE du nun nutzt. Oder meinst du was anderes?
 
  • Gefällt mir
Reaktionen: Autokiller677
@Enurian Oh, war mir bislang noch nicht bewusst. Danke!
 
joshy337 schrieb:
Apropos.. Die VB6 Community wünscht sich auch seit fast 20 Jahren 64-Bit Support.
Leider hat MS bis heute nichts geliefert bzw. es gab nie ein Update für VB Classic.
Das Problem hat schon damals angefangen, als ihr auf eine proprietäre Technologie gesetzt habt. Ja. Sie war damals sexy (und ist es bis heute), war aber schon immer eine Venusfalle die euch in eine Abhängigkeit gezogen hat unter der ihr bis heute leidet. Und wer es nach 20 Jahren immer noch nicht geschafft hat sich daraus zu befreien und seine Konsequenzen daraus zu ziehen, der hat es irgendwo auch nicht anders verdient. :-)

joshy337 schrieb:
Daher gab es immer mal wieder unabhängige Versuche, eine Alternative zu etablieren, so wie zuletzt vor 6 Monaten.
Es gibt schon seit 20 Jahren ein Projekt, welches versucht einen Ersatz darzustellen. Nämlich Gambas:
http://gambas.sourceforge.net/en/main.html
Der Vorteil, es ist ist Open-Source und es wird nach wie vor dran entwickelt.
Der Nachteil, es hat nicht alle Aspekte des orginal Visual Basic, aber vor allem ist es ein linux-zentriertes Projekt. Dadurch wirkt es teilweise wie ein Vehikel um Visual Basic Programme nach Linux zu portieren als wirklich ein Drop-in-Replacement für Visual Basic zu sein.

Man muss auch generell sagen, das sich vieles aus Visual Basic einfach überholt hat. Ja. Es hat nach wie vor Sachen die gut funktionieren. Aber es gibt auch Sachen, die würde man heute nicht mehr so machen.
Es ist so ein bisschen, als wenn man einen Oldtimer fährt. Ja. Irgendwie ist es cool aber man merkt halt auch, wie viel einem (im Vergleich zu einem modernen Wagen) fehlt.

Man muss sich halt auch bewusst machen, worum es einem wirklich geht. Ist das Ziel eher sowas wie eine Produktpflege, wo Visual Basic vorsichtig weiter entwickelt wird und der wesentliche Punkt ist aber, das meine Alt-Anwendungen auch weiter laufen.

Oder will ich was Neues was zwar die positiven Aspekte von Visual Basic beibehält aber das Ganze in die heutige Zeit hievt, wenngleich das auch ein Bruch mit der Kompatibilität bedeutet. Etwas, was Microsoft ja schon mal via Visual Basic .NET probiert hat, wo es nicht wirklich funktioniert hat. Was meiner Meinung aber vor allem daran liegt, das man aus Visual Basic ein C# gemacht hat was nur versucht so auszusehen wie Visual Basic. Und dann fällt irgendwie der eigentlich Grund für Visual Basic weg. Weil wenn es eh nur die kleine C#-Schwester ist und ich zudem alle Kompatibilität verliere, dann kann ich genauso gut direkt zu C# greifen. Die Stärke von Visual Basic ist, das es eine einfache Sprache ist und diese durch gute visuelle (RAD)Tools ergänzt wird. Das müsste dann auch ein etwaiger Nachfolger mitbringen.
 
  • Gefällt mir
Reaktionen: Th3Dan
andy_m4 schrieb:
Nicht alle Aspekte des original VB, für die mutmassliche Plattform der VB-User gar nicht vorhanden, ,
beabsichtigte Null-Kompatibilität zu VB - also im Prinzip komplett am Wunsch der Zielgruppe vorbei,
aber hey, es ist opensource...
 
Zurück
Oben