C# .Net 9, Task.WhenEach in welcher build version ?

[Micke]

Hi,
wie vielerorts zu lesen, hat Task ein WhenEach() bekommen, mit dem ich etwas spielen möchte. Allerdings kennt mein VST Compiler die Methode nicht. Nutzt jemand den aktuellen SDK build (9.0.100-preview.3.24204.13) und kann die Methode aufrufen ?

Unabhängig davon müßte ich natürlich erstmal klären, ab welchem sdk build oder file version von System.Threading.Tasks.dll der zuständige commit überhaupt eingeflossen ist. Kann ich das mittels Github und Microsofts Dokumentation ? Die commits sind ja einsehbar, aber von da ....
Das Datum scheidet m.M.n. als Zuordnung aus, da die interne Freigabe ja nicht FiFo stattfindet.

 

[Tornhoof]

Ja, du kannst das natürlich an Hand des Commits feststellen.

https://github.com/dotnet/runtime/pull/100316

https://github.com/dotnet/runtime/commit/ab2bd48741b54baa9ac416a3da56efe915826085

Dir nutzt nur nicht das PReview3, das wurde vorher gebranched, du musst schon den main sdk build nehmen.

siehe
https://github.com/dotnet/installer?tab=readme-ov-file#table (linke Spalte brauchst du)

Der einfachste Weg ist du schaust im Branch für Preview3 nach, also hier:
https://github.com/dotnet/runtime/b...te.CoreLib/src/System/Threading/Tasks/Task.cs

Da siehst du die Methode nicht...

Wenn du wissen willst wann gebranched wird für die Previews, dann ist der einfachste Weg zu schauen, wann auf master die Version geändert wird.

z.b. für Preview 4
https://github.com/dotnet/runtime/pull/99941


Anmerkung: Allgemein kannst du nicht davon ausgehen, dass z.b. Visual Studio mit den SDKs von main umgehen kann, selbst die latest public preview nicht notwendigerweise, liegt daran das VS eine eigene Version von Roslyn mitliefert die ggf. nicht mehr kompatibel ist.

 

[Micke]

vielen dank, stand ich echt aufm Schlauch.

Dir nutzt nur nicht das PReview3, das wurde vorher gebranched, du musst schon den main sdk build nehmen.

Ich nahm an "preview xyz" seien nur release tags bzw. da die Pakete publiziert werden, sei der merge in den main bereits erfolgt, wie bspw. beim #100316. Deshalb die branches gar nicht erwogen.

Wenn du wissen willst wann gebranched wird für die Previews, dann ist der einfachste Weg zu schauen, wann auf master die Version geändert wird.

gute Idee, muss man anscheinend. Denn während preview 1..3 (auch) Release Tags sind, ist es preview4 nicht. Also auch kein Garant.

 

[Micke]

* gelöst *

Hi @Tornhoof,
evtl. bist du auch diesem Folgeproblem begegnet:

Für jedes Projekt werden die gleichen 3 NU1102 Fehler geworfen:

Error (active)    NU1102    Unable to find package Microsoft.AspNetCore.App.Runtime.win-x64 with version (= 9.0.0-preview.4.24216.18)
  - Found 157 version(s) in nuget.org [ Nearest version: 9.0.0-preview.3.24172.13 ]
  - Found 0 version(s) in Microsoft Visual Studio Offline Packages
Error (active)    NU1102    Unable to find package Microsoft.WindowsDesktop.App.Runtime.win-x64 with version (= 9.0.0-preview.4.24216.16)
  - Found 154 version(s) in nuget.org [ Nearest version: 9.0.0-preview.3.24175.3 ]
  - Found 0 version(s) in Microsoft Visual Studio Offline Packages
Error (active)    NU1102    Unable to find package Microsoft.NETCore.App.Runtime.win-x64 with version (= 9.0.0-preview.4.24215.5)
  - Found 156 version(s) in nuget.org [ Nearest version: 9.0.0-preview.3.24172.9 ]
  - Found 0 version(s) in Microsoft Visual Studio Offline Packages

Die 3 Runtimes erkennt man wieder, wenn man mal "dotnet --list-runtimes" ausgeführt hat:

• Microsoft.AspNetCore.App 9.0.0-preview.4.24216.18 ....
• Microsoft.NETCore.App 9.0.0-preview.4.24215.5 ....
• Microsoft.WindowsDesktop.App 9.0.0-preview.4.24216.16 ...

Bedeutet dies, dotnet versucht ein restore der runtime Dateien über nuget, statt sie im Ordner des SDK zu suchen ? Die Anfrage an Nuget scheitert allerdings, vermutlich weil sein repository noch nicht aktualisiert wurde.
Falls dem so ist, wie kann man vermeiden, daß die existierenden runtimes ignoriert werden ?

 

[Markchen]

Auf Wunsch des TE geschlossen.