Korzystanie z async-await na .net 4

Obecnie zaczynam tworzyć aplikację, która przyniosłaby duże korzyści dzięki funkcji async-await w języku C # 5. Ale nie jestem pewien, której wersji VS i środowiska uruchomieniowego asynchronicznego użyć.

Patrząc na wykresy popularności systemów operacyjnych, będę musiał obsługiwać system Windows XP przez kolejne trzy lata. Wygląda na to, że .net 4.5 działa tylko w nowszych wersjach systemu Windows, więc muszę wybrać .net 4.0. Maszyny deweloperskie korzystają z systemu Windows 7, więc korzystanie z nowszej wersji VS nie stanowi problemu.

Teraz muszę najpierw wybrać kompilator do tego:

• VS2010 z AsyncCTP
• Wersja zapoznawcza VS2012 (i ostateczna, gdy nadejdzie), ustawiając cel na .net 4.0
• Mono (wygląda na to, że 2.12 ma async-await, wolę / jestem przyzwyczajony do VS zamiast MonoDevelop jako IDE)

Który z nich ma mniej błędów związanych z genem kodu? Patrząc na blog Jona Skeeta, VS2012 Preview używa nigdy generatora kodu niż CTP.

A co ważniejsze, którego środowiska uruchomieniowego użyć?

Czy VS2012 zawiera redystrybucyjne asynchroniczne środowisko uruchomieniowe do użytku z .net 4?

Udało mi się skompilować kod z podglądem, odwołując się do środowiska uruchomieniowego AsyncCTP. Ale ponieważ CTP ma dziwne warunki licencyjne, nie wygląda to na dobre długoterminowe rozwiązanie.

Czy powinienem skorzystać z implementacji innej firmy? Może mono ma taki?

Do dystrybucji biblioteki wolę po prostu umieścić bibliotekę dll w tym samym katalogu co aplikacja, zamiast jakiegoś instalatora.

Chciałbym też, żeby moje pliki binarne działały bez zmian na mono + Linux / MacOS. Zatem środowisko wykonawcze powinno albo być kompatybilne z tym, co mono (prawdopodobnie 2.12) ma wbudowane, albo pozwalać na użycie w systemach operacyjnych innych niż Windows.

Firma Microsoft wydała pakiet Async Targeting Pack (Microsoft.Bcl.Async) za pośrednictwem firmy Nuget jako zamiennik AsyncCTP.

Więcej na ten temat można przeczytać tutaj: http://blogs.msdn.com/b/bclteam/archive/2013/04/17/microsoft-bcl-async-is-now-stable.aspx .

O poprzedniej wersji możesz przeczytać tutaj: http://blogs.msdn.com/b/lucian/archive/2012/04/24/async-targeting-pack.aspx .

Ponieważ ten pakiet jest oficjalnie obsługiwany, teraz uważam, że najlepszą opcją do kierowania na XP + asynchroniczne byłoby użycie Visual Studio 2012 + C # 5 + Async Targeting Pack.

Jeśli jednak czujesz potrzebę kierowania na .NET 3.5, nadal możesz używać (my) AsyncBridge dla .NET 3.5 .

Jeśli jesteś otwarty na rozważenie innych języków .Net, F # może rozwiązać Twój problem. Od lat ma wyrażenie obliczeniowe async {} i jest wstecznie kompatybilny nawet z .Net 2.0. Minimalne wymaganie to Windows XP SP3. Środowisko wykonawcze można pobrać tutaj .

Możliwe jest użycie VS 12 beta do docelowej platformy .NET 4.0 przy użyciu async / await.

Musisz skopiować kod do swojego projektu, który zawiera typy, na których opiera się kompilator.

Szczegóły tutaj

Edycja: wykorzystaliśmy tę technikę i zamieniliśmy ją w bibliotekę open source o nazwie AsyncBridge: https://nuget.org/packages/AsyncBridge

Jeśli chcesz mieć możliwość dystrybucji swojego oprogramowania, myślę, że rozwiązanie Mono jest obecnie jedyną opcją. Mówisz również, że chcesz, aby efekt końcowy działał w Mono na Linuksie i OS X. Ukierunkowanie na Mono na początku wydaje się naturalnym rozwiązaniem.

Twoim następnym wydaniem jest IDE. MonoDevelop oczywiście działałby dobrze, ale mówisz, że wolisz Visual Studio.

Greg Hurlman utworzył profil do kodowania przeciwko Mono 2.8 z programu Visual Studio. Jeśli będziesz się z nim kontaktować, może on wskazywać właściwy kierunek rozwoju w porównaniu z Mono 2.11 / 2.12 w programie Visual Studio.

Oczywiście istnieje również Mono Tools dla Visual Studio, który jest produktem komercyjnym. Zakładam, że nadal jest oferowany przez Xamarin .

Możesz także być w stanie uruchomić wymagane zestawy profili 4.5 z Mono na .NET, ale nie próbowałem tego. Profil 4.5 to ścisły zestaw API 4.0. Może spróbuj i zdaj raport.

EDYCJA: Wygląda na to, że być może możesz teraz użyć Visual Studio Async CTP w produkcji

Oto, co jest napisane na stronie pobierania :

Obejmuje nową umowę EULA do użytku produkcyjnego. Uwaga - ta licencja nie stanowi zachęty do korzystania z CTP w kodzie produkcyjnym. CTP pozostaje nieobsługiwaną i używaną na własne ryzyko przedpremierą technologii. Jednak otrzymaliśmy wiele próśb od programistów o użycie CTP w kodzie produkcyjnym, więc zmieniliśmy licencję, aby to umożliwić.

Jeśli chcesz rozpocząć dystrybucję oprogramowania po wydaniu przez MS C # 5.0, możesz rozpocząć tworzenie przy użyciu AsycnCTP. W przeciwnym razie nie polecałbym ci go używać, ponieważ jest to tylko CTP, a nawet nie beta. Można to zmienić bardzo blisko etapu beta i wydania. Może być niestabilny itp.

Jeśli chcesz wprowadzić proste operacje asynchroniczne w swojej aplikacji, polecam korzystanie z rozszerzeń reaktywnych i rzeczy zbudowanych na wierzchu (reaktywny interfejs użytkownika itp.), Jest to po prostu piękne.

Jeśli chodzi o VS2012, zawiera również ten sam Async CTP, o ile pamiętam z mojego // Build / tabletu MS, który dał mi na tej konferencji.