C# .net class vs .net core async await issue

Živjo
Naredil sem nek testni api za čvek z Bitstamp apijem(samo testni app za test .net core)

Imam še winform ki uporablja ta api.

 private async void button2_Click(object sender, EventArgs e)
        {           
            var balance = await API.GetBalanceV2Async();
            label1.Text = "Done balance";
        }

        private async void button1_Click(object sender, EventArgs e)
        {
            var ticker = await API.GetTickerAsync("ethusd");            
            label1.Text = $"Done ticker {ticker}";
        }

In klik katerega koli gumba mi zablokira GUI če je napisano v coru (word by word isto) če je pa .net classic pa deluje.
Vprašanje sedaj je ali je to kakšna specifika .net core? Ga še nisem uporabljal namreč. (Testiral sem .net core 2.2 in 3.0 beta, za classic test pa mislim da 4.62)

Kaj pa dela tale API? Če daš v podpis metode async še ni magično vse skupaj asinhrono.

kingsix je 11. jan 2019 ob 05:36 izjavil:

Kaj pa dela tale API? Če daš v podpis metode async še ni magično vse skupaj asinhrono.

Točno tako. Async metoda ne zagotavlja, da se bo nekaj zaganjalo vzporedno s trenutnim Thread-om. Recimo v ASPNET zlahka narediš deadlock, če čakaš na rezultat z GetResult.

Lahko poizkusiš z BackgroundWorker, če bo kaj boljše. Drugače pa ustvari task v svojem Task factory. To ti garantira ustvarjanje nove niti.
https://docs.microsoft.com/en-us/dotnet...

Ne poznam implementacije Winforms v .NET Core, lahko da je še kakšen bug ali pa je kakšen specifičen način klicanja. Kaj pa če poizkusiš narediti kak fake task, recimo samo en sleep noter.

Offtopic: zanima me, kaj je razlog da si se odločil za winformse v netcore. Je sploh kakšna prednost glede na to da deluje samo pod windowsi?

Lahko mešaš. Samo prvo moreš razumet še en termin: netstandard.
netstandard po domače določa minimalne funkconalnosti, ki jih mora framework podpirat.
Recimo .Net Framework 4.6.1 podpira netstandard 2.0, tako kot to podpira .Net CORE 2.0.
Tukaj je seznam kateri framework-i podpirajo kateri netstandard:
https://docs.microsoft.com/en-us/dotnet...

Kar pogosta praksa je, da se da funkcionalnost v ločen class library project. V tem projektu določiš, da podpiraš netstandard in bi knjižica morala delovati normalno na obeh.
Rahel zaplet nastane, če hočeš v knjižnici uporabiti funkcionalnost, ki je del samo .Net Framework (recimo aspnet). Ko boš prišel do tja, kar vprašaj.

win64 je 11. jan 2019 ob 08:49 izjavil:

Lahko mešaš. Samo prvo moreš razumet še en termin: netstandard.
netstandard po domače določa minimalne funkconalnosti, ki jih mora framework podpirat.
Recimo .Net Framework 4.6.1 podpira netstandard 2.0, tako kot to podpira .Net CORE 2.0.
Tukaj je seznam kateri framework-i podpirajo kateri netstandard:
https://docs.microsoft.com/en-us/dotnet...

Kar pogosta praksa je, da se da funkcionalnost v ločen class library project. V tem projektu določiš, da podpiraš netstandard in bi knjižica morala delovati normalno na obeh.
Rahel zaplet nastane, če hočeš v knjižnici uporabiti funkcionalnost, ki je del samo .Net Framework (recimo aspnet). Ko boš prišel do tja, kar vprašaj.

Full support za .Net standard 2 mislim da podpira šele 4.7.1. 4.6.1 pa preko shim-ov, kjer ti naštepa v projekt 20+ dodatnih dll-jev

detroit je 11. jan 2019 ob 09:00 izjavil:

mal po spominu brskam, ali bi moral potem za API izbrati .net standard ali kar pustim classic lahko?

drugače pa thx nisem vedel da se da mixat:)

Web api je classic ali pa .NET Core, standard je samo "dogovor" in ne framework

sicer nismo prišli do dna buggy .coru ampak bom stestiral pa javim ko bo čas thx vsem