Was ist der Aufrufkontext von GetCoverArtFromCoverArtPfad
Ist GetCoverFromWeb selbst ein Task(Of Irgendwas)?
Die Bedeutung verändert sich dadurch natürlich.
Was passiert bei

Es werden alle Methoden nacheinander aufgerufen. Aber sobald in GetCoverArtFromCoverArtPfad() das Await erreicht wird, geht es mit Methode2 weiter.
Wenn Du aber ne Function draus machst, bekommst Du einen Task wieder, den Du per Await auch aufrufen musst.

Aber dann wird auch auf GetCoverArtFromCoverArtPfad gewartet, bevor es mit Methode2 weitergeht.

Ich verstehe es so.
Wenn man Await vor den Aufruf einer Methode schreibt, dann ist eine Async Sub dasselbe wie eine Async Function as Task, so eine Funtion returnt dann nämlich nichts.
Eine Async Function as Task(Of T) returnt auch T wenn sie Awaitet wird.

Werden diese Methoden nicht Awaited, dann ändert sich das Verhalten. Die Async Sub fährt los und arbeitet im Nirvana.
Die Async Function as Task returnt dann genauso wie die Async Function as Task(Of T) eine Task. Und das heißt da läuft eigentlich nur der Teil des Codes, der vor der Task läuft die indirekt durch das Await returnt wird.
Die Tasks müssen dann ja erstmal gestartet werden.
Und nu weiß ich nicht was passiert, wenn die nicht gestartet werden.

Vielleicht erklärst du was passieren soll.

Das streicht der rot an weil die Get-Methode nicht Async ist. Denk auch nicht, dass das geht.
Aber als die Methode noch eine Sub war, kann das wohl kaum der Aufruf dieser Methode gewesen sein.

kafffee schrieb:

Ich möchte halt, dass im Getter meiner Property das Bild aus dem Internet geladen wird und in die Property geschrieben wird.

Dazu muss es noch lange nicht asynchron sein.

Ich versteh auch noch nicht, was mit der Sub Variante dann das Problem ist.

GetAwaiter hab ich noch nie genutzt.

ConfigureAwait da biste auch schon im fortgeschrittenen Bereich von Async Await. Das ist glaub ich sogar ein relativ junges Feature.

kafffee schrieb:

Wie würdest du es machen?

Na wahrscheinlich ungefähr so wie du auch im ersten Post. Wenns funktioniert, dann funktionierts. Ansonsten wie gesagt, ist nicht klar "was genau" überhaupt machen.
Was davon tut Post 1 nicht? Und pack zu Post 1 noch den Aufruf, wann läuft das überhaupt? Auch in der Property? Das wäre dann der Größte Unterschied zwischen deinem und meinem Ansatz.

Eine Property soll den Wert im Allgemeinen nicht immer neu holen, wenn die Property abgegriffen wird. Und genau sowas täte ja die Pseudocode-Variante von Post 3.
Wenn da zwei verschiedene Sachen gleichzeitig diese Property wissen wollen, dann wird zweimal das Bild geholt.
Für mich hört sich das Ganze allgemein nicht mal veränderlich an. Das Bild muss ein einziges Mal geholt werden. Und dann kann ich die Property dazu 100-mal abrufen.
Und dann hol ich vielleicht irgendwann mal ein anderes Bild.

Post 3 kann nicht der Aufruf von Post 1 sein.

der post#9-Code sieht mir verdächtig aus.
die Property müsste einen Async-Getter haben, wenn das gehen soll.
und dann muss man den Getter immer mit Await aufrufen.

Anstatt so ein gefummel, warum nicht einfach ein Event nutzen? Zutaten vom Koch zubereiten lassen, kanner im Hintergrund in der Küche machen, stellt dem Kellner das Gericht hin wenn fertig, der Kellner bringt es dir und du feierst dann das Event Gaumenschmaus und hast alles was du brauchst am Tisch.

kafffee schrieb:

Wir reden bestimmt aneinander vorbei. Wieso meinst du das?

Weil eine Sub nichts zurückgibt, der Compiler dir das nicht kompilieren würde. Siehe auch dein Post 5, da hatten wir das schonmal.

Ich bin anderer Meinung. Aber als VBler erkennt man das nicht wenn man keine Sprachen mit C-Syntax beherscht, in C# ist das deutlicher/besser zu erkennen. (Weil in VB nicht "function XXX as Sub" geschrieben wird), bei C-Style steht nachdem AccessModifier immer der ReturnType.

learn.microsoft.com/en-us/dotn…erence/builtin-types/void

void(in VB Sub) ist ein Return-Type, der kommt dann zurück, dieser Typ kann aber keinen Wert annehmen.

Das hat wenig mit Meinung zu tun, das kompiliert weder in vb.net noch in c#.
In VB ist das natürlich genauso begründet wie in c#, nur wird das in der Sprache anders verdaut. Am Ende muss IL rauskommen können.

Haudruferzappeltnoch schrieb:

Werden diese Methoden nicht Awaited, dann ändert sich das Verhalten. Die Async Sub fährt los und arbeitet im Nirvana.

Genau, der läuft dann einfach asynchron los und wird nie synchronisiert. Als würdest du quasi einfach nen Thread starten.

Haudruferzappeltnoch schrieb:

Das ist glaub ich sogar ein relativ junges Feature.

Das gibt es tatsächlich schon recht lang. Erinnere mich noch an die Anfangszeiten von TAP - da war das schon in den damaligen MSDN-Docs auch gelistet und wurde verwendet.
Wichtig ist aber ConfigureAwait(False) eigentlich nie zu nutzen, wenn man nicht explizit weiß, was man tut. Das sorgt nämlich dafür, dass die Methodenausführung nach dem Await nicht mehr im aktuellen Synchronisierungskontext (z.B. hier UI-Thread) läuft, sondern irgendeinen verfügbaren Thread im Pool verwendet. Das ist ok, wenn man danach im UI-Thread nichts mehr machen muss, aber sonst bricht das.

kafffee schrieb:

GIbt es Unterchiede in der Benutzung von Async Subs und Async Functions As Task (of Type)
Ich kann mir nicht erklären was ich falsch mache....?

Nein. Nur dass der Task etwas zurückgibt, was nicht void/Sub ist. In einem normalen Async Task beendet ein Return die Ausführung. Im Async Task(Of T) auch, aber es wird halt noch ein Wert mitgegeben (z.B. Return 1. Handhabung ist aber genau gleich.

Hinweis: Nur weil du async-await benutzt heißt das noch nicht, dass die Methode automatisch asynchron ist. Sie wird nur an den Await-Stellen sozusagen aufgeschnitten und in verschiedene Aufrufteile unterteilt. Das ist ein Syntactic Sugar, damit man nicht Task.ContinueWith-Ketten bauen muss und die gewohnte Methodenstruktur beibehalten kann. Wenn das ganze nur in Teilen in anderen Threads läuft, rennt der Rest dir trotzdem auf dem UI-Thread bzw. im originalen Synchronisierungskontext, von dem aus aufgerufen wurde. An irgendeiner Stelle muss die asynchrone Arbeit auch wirklich auf einen neuen Thread ausgelagert werden. Erst dann wird der aktuelle (UI-)Thread entblockt, der Aufgabencode läuft asynchron/parallel und die Methodenausführung wird erst fortgeführt, sobald der Task durch ist. Dann bist du wieder im blockenden Bereich.
Um selbst so einen asynchronen Task zu bauen, muss man ihn mit Task.Run erstellen und dann zurückgeben. Der ist dann für andere Methoden awaitbar. Die bauende Methode muss aber selbst nicht Async markiert sein, sondern nur den Return-Type Task oder Task(Of T) haben. Async-Keyword brauchst du nur, wenn du im Methoden-Body aktiv awaiten willst.

Properties sind Stand jetzt nicht als Async markierbar. Das geht nur für Methoden und Lambdas.
Um dir zu helfen, benötigen wir am besten mal einen kompletten Code aller relevanten Methoden, die hier irgendwie awaited werden. Teile deines Codes können so nicht funktionieren, weil sie einfach nicht möglich sind und so ist es schwierig, da richtig einzutauchen. Schätze hier werden noch verschiedene Ansätze miteinander vermischt und dann kriegst du komische Ergebnisse, bei denen du selbst nicht weißt, was du erwarten würdest.

Viele Grüße

kafffee schrieb:

ErfinderDesRades schrieb:

und dann muss man den Getter immer mit Await aufrufen.

Schwierig. Ist per Binding an die View gebunden.

Ich denke, es geht eben nicht, was du vorhast.
Async/Await verhält sich sehr speziell.
zunächstmal wenn eine async-Methode nicht await aufgerufen wird, so ist sie nicht nebenläufig - also sinnlos.
Dann: die awaitende Methode returnt vorzeitig!
Sie returnt am Await-Schlüsselwort.
Später, wenn die asynce methode durch ist, springt der Programm ablauf wieder hinter die Await-Stelle und setzt (mit den Daten) fort.
die awaitende Methode returnt also zweimal.
Also imo gehts nicht, an eine asynce Property zu binden.

Das Asynce muss annerswo laufen in der Viewmodel-logik.

ErfinderDesRades schrieb:

zunächstmal wenn eine async-Methode nicht await aufgerufen wird, so ist sie nicht nebenläufig

Doch, nebenläufig ist der Task schon, wenn er entsprechend an einer Stelle Arbeit auf einen neuen Thread auslagert. Aber es gibt halt dann kein Warten darauf, sondern der Rest der aufrufenden Methode läuft einfach direkt weiter. Also ja, sinnlos ist es natürlich, weil das Pattern dann keinen Sinn macht und man auch einfach so einen Thread auf den Pool legen kann.

ErfinderDesRades schrieb:

Also imo gehts nicht, an eine asynce Property zu binden.

Das Asynce muss annerswo laufen in der Viewmodel-logik.

Ja. Ist eigentlich relativ blöd, weil es keinen technischen Grund gibt, asynchrone Properties nicht zu erlauben. Ist halt semantisch wohl nicht so sinnvoll definiert. Daher geht das nur über eine asynchrone Methode, die das macht und dann den Wert an der Ziel-Property, die gebunden wird, setzt. Bis dahin muss die Property halt irgendeinen Default-Wert (z.B. default(T) oder halt null, wenn Nullable) halten. Die Methode sollte halt direkt einen CompletedTask zurückgeben, wenn sie schon gelaufen ist oder sie setzt halt nochmal neu (je nach Use-Case). Im Endeffekt macht eine Property intern ja auch nichts anderes, als eine Getter-Funktion auszuführen.

Viele Grüße

wie gesagt, mir macht das Binden an eine Async-Property keinen Sinn. Das Binding braucht die Daten sofort - es muss sie ja anzeigen.
Es kann ja nicht warten, und solange "nicht" anzeigen.
Oder anders: Das Binding reagiert ja auf PropertyChanged. Ein PropertyChanged wäre aber verfrüht, wenn die Daten noch garnet da sind.

(my 5 ct - will mich da nu nich festbeissn)