Laden...

Performance-Verbesserungen in .NET 6

Erstellt von Abt vor 2 Jahren Letzter Beitrag vor 2 Jahren 1.803 Views
Abt Themenstarter:in
16.792 Beiträge seit 2008
vor 2 Jahren
Performance-Verbesserungen in .NET 6

Microsoft hat wahnsinnig viel in die Performance-Verbesserungen von .NET investiert, was nun in einem riesigen Blog-Post für Entwickler veröffentlicht wurde.
Wer also mal Zeit und Lust hat: Performance Improvements in .NET 6

Warnung: ausgedruckt ist der Blog Post 118(!) DIN A4 Seiten lang - aber sehr beeindruckend!

T
2.219 Beiträge seit 2008
vor 2 Jahren

Danke für die Info, schaue ich mir bei Zeiten mal vollständig an.
Die Themen umfassen wirklich die wichtigsten Teile samt Benchmarks, was wirklich sehr schön ist.
Wenn man sich auch die Issues bei Github anschaut, findet man auch eingie Punkte für Performance Verschlechterungen durch Änderungen an er Runtime.
Hier zeigt sich auch, wie wichtig das Thema bei der Umsetzung von .NET ist.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

Abt Themenstarter:in
16.792 Beiträge seit 2008
vor 2 Jahren

Wenn man sich auch die Issues bei Github anschaut, findet man auch eingie Punkte für Performance Verschlechterungen durch Änderungen an er Runtime.

Beispiel? Mir ist das nur bei Issues bekannt, bei denen man Abhängigkeiten (zB ans Betriebssystem) ändern musste, bei Bugfixes und bei Security Improvements.

T
2.219 Beiträge seit 2008
vor 2 Jahren

@Abt
Gibt bei der suche nach "[Perf]" einige Treffer.

Hir sind ein paar Issues, die sowohl Regressionen als auch Vorschläge für Optimierungen liefern, hab ich nur auf die schnelle gefunden.
https://github.com/dotnet/runtime/issues/54165
https://github.com/dotnet/runtime/issues/52296
https://github.com/dotnet/runtime/issues/50737

Hatte vor ca. 2-3 Monaten auch ein Issue bei dem es durch Änderungen bei CultureInfo zu höherer Laufzeit kam.
Ebenfalls gab es zu der Zeit einige Issue wo dann der Laufzeit ANstieg in % für die jeweiligen Methoden dran stand.
War schon interessant zu sehen, dass auch Performance Verluste als Fehler berücksichtigt wurde.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

6.910 Beiträge seit 2009
vor 2 Jahren

Hallo,

Abhängigkeiten (zB ans Betriebssystem) ändern musste

Es gibt noch ein paar (wenige) andere, bei denen latente Bugs behoben wurden auf Kosten von etwas Performance, aber Korrektheit ist wichtiger.
Bei diesen Issues ist aber das Potential hoch, dass durch weitere Optimierungen z.B. im JIT dieser Performance-Verlust wieder ausgeglichen werden kann.

Aktuell -- also bevor .NET 6 fertig ist -- gibt es noch ein paar "Tuning-Bugs" v.a. bei den Themen "loop alignment" und "profile guided optimization". Bei letzterem teils da alte Profil-Daten verwendet wurden.

Aber mit https://github.com/dotnet/performance gibt es für .NET ein eignes Repo für die Benchmarks und diese werden automatisch und regelmäßig ausgeführt. Sollten dabei Regressionen festgestellt werden, so gibt das auch (mehr od. weniger automatisch) ein Issue im runtime-Repo so dass dies anschließend genauer untersucht werden kann.
In den letzten Jahren hat sich bei .NET eine richtige Performance-Infrastruktur inkl. Team entwickelt (finde ich gut so).

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

J
61 Beiträge seit 2020
vor 2 Jahren

Microsoft hat wahnsinnig viel in die Performance-Verbesserungen von .NET investiert, was nun in einem riesigen Blog-Post für Entwickler veröffentlicht wurde.
Wer also mal Zeit und Lust hat:
>

Warnung: ausgedruckt ist der Blog Post 118(!) DIN A4 Seiten lang - aber sehr beeindruckend!

Danke, sehr interessant, auch wenn es ganz schön Zeit in Anspruch genommen hat.

Bei

grab a large mug of your favorite hot beverage, and settle in

frage ich mich, wie groß die Tasse sein muss. Und kalt ist das Getränk wohl auch nach Lesen eines Viertel des Textes.

T
2.219 Beiträge seit 2008
vor 2 Jahren

Gerade gelesen, gfoidl wird in dem Blog Beitrag auch erwähnt 🙂
Sehr schön!

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

6.910 Beiträge seit 2009
vor 2 Jahren

Hallo T-Virus,

🙂

Es freut mich meinen Nickname da zu lesen (aber auch schon in ein paar der vorherigen Blog-Posts dieser Serie) und es ist mir auch eine Ehre dort erwähnt zu werden, denn es ist wohl der größte Dank und Wertschätzung der Beiträge zum .NET-Code. V.a. wenns Stephen Toub schreibt, da ich ihn als eher kritisch und sehr akkurat (als positive Eigenschaften) einschätze (persönlich kenn ich ihn nicht).

Dass .NET open source entwickelt und auch gelebt wird, gefällt mir sehr gut und ich finde die .NET Foundation und Microsoft machen dies hervorragend.
Durch das Verfolgen von Pull Requests lässt sich da schon eine Menge lernen, denn es gibt gewisse "Dinge" in .NET die man als "normaler" .NET Entwickler (~ Benutzer von .NET) einfach nicht auf dem Schirm haben kann, auch da sie nirgends dokumentiert sind und nur im Code erlesbar sind, aber wer liest sich schon durch zig-tausend Zeilen GC-Code?
Natürlich kommt es auch da auf die Zielsetzung darauf an. Bestimmte Punkte die in PRs (und Issues) besprochen werden sind für 99,99 % der C#-Programmierer irrelevant. Wer sich aber in den Niederungen von .NET weiterbilden will, so sind dort genau die richtigen Leute (meist die jeweiligen Entwickler / Architekten) am Werk. Genauso ist es mit eigenen PRs und deren Review. Sollte es Punkte geben, bei denen man "ansteht", so wird einem der Weg bereitet und Hilfestellungen zum Erlernen der nötigen Schritte gegeben, so dass man weiter kommt -- und all dies in einer freundlichen netten Umgangsform, im Gegensatz zu manch anderen open source-Communities. Besonders gefällt mir bei PR-Reviews (allgemein), dass es so gut wie nie heißt "mach es so", sondern "mach es so, weil [Begründung]" und somit auch der Lerneffekt mit an Bord ist.
Ein weiterer netter Punkt ist, dass mit neuen Typen und / oder Sprachfeatures von C# vorzeitig "probiert" werden kann und dabei von den "Machern" selbst das Review dazu kommt. Diese Möglichkeit gibt es sonst nicht sehr oft. Als beispielsweise Span mit .NET Core 2.1 eingeführt wurde, gab es nicht sehr viel Info darüber, mehr od. weniger von offizieller Seite nur einen Blog-Post in dem die Verwendung und Vor-/Nachteile grob erklärt wurden. Die Feinheiten konnten in diesem Blog aber nicht erwähnt werden, da es eben nciht die Zielsetzung dieses Beitrags war. Hat man sich jedoch an PRs rund um Span beteiligt, so gab es Feedback (auch ein Approve ist Feedback) von den JIT-Architekten, etc. also genau von den Leuten welche Span selbst implementiert hatten. Ein besseres "battle testing" kann ich mir diesbezüglich gar nicht vorstellen.
Edit: Od. wie jetzt aktuell für .NET 6 mit den NativeMemory-Methoden für Alloc, AlignedAlloc, ReAlloc, etc. Wann verwende ich Alloc und wann AlignedAlloc bzw. wie schaut das standardmäßige Alignment bei Alloc aus? Generell wann ist es sinnvoll auf diese Methoden zurückzugreifen bzw. was sind potentielle Anwendungsgebiete dafür, ist es eine bessere Alternative zu Marshal.AllocHGlobal? Diese und ähnliche Fragen (sowie deren Antworten) tauchen bei PR Reviews auf, da Teile vom Team das im Moment auch noch nicht wissen und so ist man "live dabei" um eben mit-zulernen. Ob man diese APIs jemals brauchen wird ist eine andere Frage, aber ich finde es immer interessant zumindest einen Überblick über meine "Werkzeugkiste" zu haben, denn es mag ja sein dass ich es irgendwann brauchen kann (wobei für diese APIs habe ich schon konkrete Anwendungsfälle).

Die Reise von und mit .NET geht weiter, neue Typen und APIs kommen hinzu und deren Verwendung will erlernt / erprobt werden. Warum also das nicht per PR für .NET selbst probieren od. schon bei der Diskussion in den Issues seinen Senf dazu geben? .NET ist open source und wer will kann sich an der Weiterentwicklung beteiligen. Da die Community freundlich ist, gibt es auch keinen Grund sich nicht zu trauen (allerdings sollte man schon wohl überlegt agieren 😉).
Alleine das Erstellen von Issues zu Wünschen, Performance-Einbußen*, etc. ist hilfreich. Die hauptsächlichen Entwickler von .NET "leben in ihrem eigenen Universum" und wissen womöglich gar nicht welche Anwendungen wir so erstellen und worauf es dabei ankommt. Daher kann durch Beteiligung an Diskussionen ihr Blick und Verständnis erweitert werden und sie können so ihre Priorisierung von Features, etc. adaptieren. Dabei reicht auch oft schon ein "Like" zu einer bestehenden Issue um dieser mehr Gewicht zu geben.

* Wie in diesem Thread schon erwähnt wurde, wird die Performance von .NET automatisch überwacht, daher werden viele Regressionen auch automatisch gemeldet. Aber: es können nur jene Szenarien überwacht werden, für die auch entsprechender Benchmark-Code erstellt wurde. D.h. es nicht jedes mögliche Szenario und Konstallation abgedeckt, da dies einfach nicht umsetzbar ist. Daher gibt es die Möglichkeit, wenn auch nicht mit sehr hoher Wahrscheinlichkeit, dass ein bestimmtes Szenario aus einer Anwendung eine Regression erfährt und wenn diese per Issue gemeldet wird, so kann dies untersucht werden und ggf. der Benchmark entsprechend angepasst / erweitert werden, damit diesen Sicherheitsnetz für Performance engmaschiger wird.

Jetzt bin ich ein wenig abgeschweift...

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

3.825 Beiträge seit 2006
vor 2 Jahren

Ich benutze Visual Studio seit der Version 2003, also seit 18 Jahren. Ich hatte noch nie ein Problem mit der Performance der Applikation.

Optimieren muss man nur die Datenbankzugriffe. Der Rest war immer schnell. Ich baue sogar manchmal Verzögerungen ein damit man sieht das was passiert.

Anders ist es bei der Entwicklungsumgebung. Die wird immer langsamer.

Seit VS 2019 ist das ganz schlimm geworden. Hab mir extra einen neuen Rechner mit SSD Array aufgebaut, ist immer noch sehr langsam.

Es kommt oft die Meldung "Code Änderungen werden angewandt ...". Ich denke das hat mit dem geplanten Neucompilieren von Änderungen zu tun. Oder VS hängt einfach mehrere Minuten.

Ganz schlimm ist es beim Kompilieren für iOS : Das Verbinden mit einem Mac dauert ca. 5 Minuten, dabei ist alles gesperrt, man kann nichts eingeben. In 50% der Fälle klappt es nicht, man muss es wiederholen. Es gibt keine Meldung ob die Verbindung erfolgreich war. Nach 10 Minuten beendet sich die Verbindung zum Mac.

Ich denke dass ein schnellerer Rechner keinen Sinn macht, da wartet man dann 4 statt 5 Minuten.

Ich bezweifele dass die Entwicklung in die richtige Richtung geht.

Grüße Bernd

Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3

T
2.219 Beiträge seit 2008
vor 2 Jahren

@BerndFfm
Dann warte mal auf VS 2022.
Diese soll als 64 Bit erscheinen, was eines der Probleme bei mir ist.
VS läuft i.d.R. bei mir schon am 32 Bit Limit des Prozess Speichers, was dann zu längeren hängern führt.
Ich bin zuversichtlich, dass sich dies mit VS 2022 bessert.

Alternativ kannst du dir auch mal Rider anschauen.
Wird auch häufig benutzt und soll sehr gut laufen.
Hab es aber selbst noch nicht verwendet oder geprüft.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

Abt Themenstarter:in
16.792 Beiträge seit 2008
vor 2 Jahren

Optimieren muss man nur die Datenbankzugriffe. Der Rest war immer schnell.

Naja, da will ich nun mal eine Bubblesicht vorwerfen 🙂
Du baust halt eher isolierte Applikationen, die gefühlt keinen direkten Nutzen daraus schließen.
Da bist Du (als Einzelperson, wie auch ich) einfach ein vergleichbar kleines Licht, weil die Summe zählt.

So ähnlich wie "wenn jeder seine Standby Geräte ausschalten würde, könnten wir ein Kraftwerk ausschalten".

Ich bezweifele dass die Entwicklung in die richtige Richtung geht.

Ich sehe, dass es in genau die richtige Richtung geht!

Hintergrund
.NET war früher mal eine Plattform, die vor allem monolithische Zielsysteme fokussiert hat; typisch die dicke Desktop-Anwendung und die dicke Single Server Anwendung.
Diese Zeiten haben sich massiv geändert.

Spätestens als Xamarin in die .NET Welt kam hatte man oft Performance Probleme: weil das Framework selbst vergleichweise unperformant war, und man daher Dinge selbst implementiert hatte, oder damit leben musste.
Performance hat nämlich zwei primäre Aspekte: Geschwindigkeit und Effizienz.

Und Effizienz ist im mobilen Sektor alles, was zählt: ineffiziente Anwendungen auf mobilen Plattformen bekommen den iOS / Android Hammer geschwungen, weil sie Akku ziehen.
Die Apps werden abgeschossen, die Apps erhalten Benutzerwarnungen und wurden oft daraufhin deinstalliert. Der Entwickler war - an manchen Ecken - gefangen in einer ineffizienten Welt.
Spätestens mit Flutter und React Native gab es dann nicht nur Effizienz-Nachteile für Xamarin, sondern auch immense Nachteile in der Art und Weise, wie man programmieren kann.
Xamarin ist daher - aktuell - auf dem Abstellgleis und verliert - durch .NET 5/6 zwar etwas gebremst - weiter ihre sehr geringen Marktanteile.

Weiter dann in der Web-Welt: während .NET immer aufgeblähter wurde, haben andere Technologien - allen voran NodeJS - in seinem schlanken und effizienten Wesen .NET an vielen Ecken den Rang abgelaufen; und das alles mit einer Single-Thread Umgebung.
Der Usage-Index auf StackOverflow (Menge an gestellter Fragen zu einer Technologie) ist von 11 % in 2009 auf 1% in 2015 abgestürzt; prozentual so sehr ist nichts anderes eingestürzt: ein klares Zeichen, dass .NET mehr als nur auf dem absteigenden Ast war.
.NET musste was tun, oder es war tot.

Durch den allgemeinen Thread Mobile First / Cloud First kam dann eben auch ASP.NET Core und danach .NET Core raus, was nicht nur eine viel bessere Grundarchitektur hatte, sondern auch extrem viel in Effizienz gebuttert wurde. Es war konkurrenzfähig als Plattform.
Der Lohn für diese Arbeit, für die Effizienz ist, dass .NET Core / .NET 5 + heute zu den performantesten und beliebtesten Plattformen gehört, die es gibt. Bewiesen wird das regelmäßig auf TechEmpower und den Developer Journeys.

Und was für Sekundärfolgen hat das?
Man braucht viel weniger Ressourcen, um identisches auf die Beine zu stellen -> Nachhaltigkeit.

Das sind in der Größenordnung Einsparungen im Millionen-Dollar-Bereich.

Durch die viel effizientere Grundimplementierung ergeben sich also Dinge wie:* Viele Projekte, in allen Welten, sind dadurch erst finanziell umsetzbar durch den geringeren Ressourcen-Verbrauch

  • Viele Projekte, in allen Welten, sind dadurch erst technisch umsetzbar durch den geringeren Ressourcen-Verbrauch
  • Compute Based Billings (zB Cloud) werden dadurch viel billiger umsetzbar, bei einer höheren Skalierbarkeit
  • Jede Software wird nachhaltiger, weil weniger Ressourcen und damit Strom / Hardware benötigt werden

Nachhaltigkeit
Um beim Thema Nachhaltigkeit zu bleiben: das ist sowohl real wie auch politisch mittlerweile im Fokus.
Microsoft hat das schon vor paar Jahren erkannt und will ab 2030 CO2-negativ sein und bis 2050 jeglich erzeugtes CO2 entfernen, das sie verursacht haben.

Während die Welt CO2-Neutralität erreichen muss, sollten diejenigen von uns, die schneller vorangehen können, dies auch tun. Deshalb kündigen wir heute ein ehrgeiziges Ziel und einen neuen Plan an, um Microsofts CO2-Fußabdruck zu reduzieren und letztendlich ganz zu beseitigen. Bis 2030 wird Microsoft CO2-negativ sein, also mehr Kohlendioxid aus der Atmosphäre entfernen, als wir verursachen. Bis 2050 werden wir den gesamten Kohlenstoff aus der Atmosphäre entfernen, den Microsoft seit seiner Gründung im Jahr 1975 entweder direkt oder durch seinen Stromverbrauch emittiert hat.

Sie investieren extrem in nachhaltige Projekte, extrem in erneuerbare Energien. Viele ihrer Azure Datacenter werden ausschließlich durch erneuerbare Energien betrieben.
Azure-Nachhaltigkeit: nachhaltige Technologie | Microsoft Azure
Viele Firmen werden dem nachziehen, und natürlich wird das auch den IT Betrieb treffen.
Aus meinem Umfeld - Maschinenbau, Industrie, Landwirtschaft - begegnen mir Zahlen um die 10-15% CO2-Einsparung trotz Wachstum bis 2030 - und das selbst bei Energie-fressenden Maschinenbauern wie Laser-Hersteller.
Und es gibt schon länger Projekte, die die Effizienz von Software in Unternehmen messen; und das wird auf die Software Entwickler der Zukunft und damit auf die Technologieauswahl Auswirkungen haben - auf manche weniger, auf manche mehr.
Microsoft hat dafür bereits einen CO2 Calculator; durchaus auch mit der Story, dass eine Cloud i.d.R. eben CO2-effizienter ist als ein Inhouse Datacenter, das die Möglichkeiten gar nicht haben haben kann.
https://azure.microsoft.com/de-de/blog/microsoft-sustainability-calculator-helps-enterprises-analyze-the-carbon-emissions-of-their-it-infrastructure/

Ich hab bei mir in der Firma Kollegen (zugegeben, ich bin bei einem von Grundauf sehr Engerie-Sektor-lastigem Beratungshaus), die nichts anderes machen als Unternehmen bei ihrem CO2 Footprint und bei ihrer CO2 Effizienz zu unterstützen.
Das ist ein mega gefragtes Thema und bei vielen Kunden mittlerweile ein Prio-Kriterium bei der Lieferanten / Cloud / Plattformauswahl.

myCSharp
Ein Blick hinter die Kulissen von myCSharp: ich denke ich kann von mir behaupten, dass ich ein durchaus überschnittliches Wissen habe, was das Thema Architektur und Co bei .NET betrifft und entsprechend ist das auch in myCSharp.de geflossen. Was ich nicht unbedingt habe, einfach weil ich das auch nicht leisten kann, ist das Thema "Unter der Haube" Wissen, was das Thema Performance betrifft.
gfoidl hat das aber und hat hier Optimierungen in das Forum gebracht, dass wir mehr als 80% der Betriebskosten einsparen konnten; maßgeblich CPU und Datenbank-Kosten.
Ich habe oft seine Pull Requests nicht verstanden, da darin Dinge enthalten waren, die mir zuvor in 19 Jahren .NET noch nicht vor das Auge gekommen sind 🙂
Aber er ist sehr akribisch, hat immer gut dokumentiert und die Leistung verglichen, um uns das verständlich zu machen, was der Code tut - und warum er effizienter ist.
Wir sind mittlerweile, maßgeblich durch die mega Leistung von gfoidl auf der kleinsten Instanz-Stufe, die wir für uns in Azure verwenden können. Jede Stufe drunter fehlen uns Features, die wir wollen.
Selbst wir kleine Webseite sparen jetzt Geld - jeden Monat. Jede weitere Optimierung an .NET wird also nicht in weitere Kosteneinsparungen fließen können - aber die Webseite wird schneller. Den Nutzen haben also die Besucher.
Unser Nutzen ist, dass wir Geld sparen. Und da ich die myCSharp-Rechnung begleiche bin ich gfoidl sehr dankbar und mehr als ein Ausgleichsbier schuldig 🙂

Fazit
Ich bin sehr froh, was Microsoft da macht und für mich geht es auch allein wegen der Nachhaltigkeit in die richtige Richtung. Dass ich damit nicht alleine bin sieht man an der enormen Beliebtheit der neuen .NET Welt, die sie mittlerweile gewonnen hat und auch von Enterprise-Unternehmen wieder vermehrt aktiv verwendet werden.
.NET ist heute so effizient, dass selbst Themen wie AI und Machine Learning mit .NET performant umsetzbar sind - und .NET wieder wächst.

Wäre das nicht passiert hätte ich mir wohl mittlerweile eine andere Plattform suchen müssen.


Dann warte mal auf VS 2022.
Diese soll als 64 Bit erscheinen, was eines der Probleme bei mir ist.
VS läuft i.d.R. bei mir schon am 32 Bit Limit des Prozess Speichers, was dann zu längeren hängern führt.

... was halt auch immer auch ein Zeichen dafür sein kann, dass die Solution Organisation nicht so ist, wie sie sein sollte (bitte keine Diskussion nun), was auch Microsoft bei dieser Sache immer wieder betont hat.
Nur weil VS2022 nun 64 Bit unterstützt heisst das ja nicht, dass man nun seine Solution weiter aufblähen sollte.

Ich hab sowohl VS2022 Preview wie auch Rider aktiv; beide haben ihre Fanbase - beide ihre Vor- und Nachteile.
Dass VS im allgemeinen immer mächtiger wurde und leider an der ein oder anderen Stelle auch langsamer; nicht unwahr.
Viele Performance-Probleme machen aber auch Erweiterungen, zB. ReSharper.

J
61 Beiträge seit 2020
vor 2 Jahren

Vielleicht sollte man an der Stelle VS von .NET trennen. Ich habe Bernds Beitrag nicht gegen die Entwicklung von .NET aufgefasst, sondern von VS.

Insofern wäre der Beitrag wohl besser bei VS2022 Preview aufgehoben statt bei .NET.

Abt Themenstarter:in
16.792 Beiträge seit 2008
vor 2 Jahren

Ich hab mich vor allem auf..

...Ich hatte noch nie ein Problem mit der Performance der Applikation...
...Optimieren muss man nur die Datenbankzugriffe. Der Rest war immer schnell...
...Ich baue sogar manchmal Verzögerungen ein damit man sieht das was passiert...

bezogen.

2.078 Beiträge seit 2012
vor 2 Jahren

..., dass die Solution Organisation nicht so ist, wie sie sein sollte (bitte keine Diskussion nun)

Du möchtest keine Diskussion dazu, aber hast Du Quellen dazu? Ich will nicht diskutieren, sondern mich nur belesen ^^
Ich kenne nur deinen eher auf Übersicht ausgelegten Artikel zur Ordner-Struktur: [FAQ] Ordnerstruktur für .NET Projekte
Ob und wie ich VisualStudio durch die Solution-Organisation optimieren kann, würde mich aber sehr interessieren.

3.825 Beiträge seit 2006
vor 2 Jahren

T-Virus : Ja, ich bin sehr gespannt auf VS 2022. Vor allem 64 bit und Maui interessiert mich.

Ja, sorry, geht mehr um VS als um .NET.

Grüße Bernd

Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3

Abt Themenstarter:in
16.792 Beiträge seit 2008
vor 2 Jahren

Du möchtest keine Diskussion dazu, aber hast Du Quellen dazu? Ich will nicht diskutieren, sondern mich nur belesen ^^

Wegen mir kann man da disktuieren, bin der letzte, der sowas generell unterbindet - aber dann gern in nem anderen Thread.
Nur bitte nicht hier 🙂

Zu den Quellen:
Vielleicht missverständlich ausgedrückt, aber Microsoft sagt Dir nicht "wie es exakt geht", weil es hier keinen generellen Weg gibt.
Wenn die Solution so riesig ist, dass die Leute kaum arbeiten können und die Build Times riesig sind - dann stimmt was nicht.
Die Zeichen, die da Microsoft mit dem Zaunpfahl zB in ihren Videos gibt sind da sowas wie

  • bist Du Dir sicher, dass Du das alles in einer Solution brauchst?
  • Hast Du schon mal vom Auslagern in NuGets gehört?

Die Regeln kommen da ja eher mittlerweile aus dem Dev Bereich:

  • Software Architektur -> Paketierung
  • DevOps -> Build Time so kurz wie möglich.
    Wenn die Build Time einer Solution länger dauert als die von Windows (~10 Min sagt man), dann sollte man sich wohl mal was überlegen 🙂

Es gab mal einen Guide, was man in einer Haupt Solution haben sollte und was nicht; aber finde den in den Docs nicht mehr. Vielleicht weg oder archiviert.
Das einzige, das ich aktuell finde, ist Team Development with Visual Studio .NET and Visual SourceSafe - Structuring Solutions and Projects