4 ms·

I can't really make heads or tails of this, it's still fairly complicated and I'm just not invested enough in it to read everything with a fine toothed comb. W

by bmurphy1976 10y ago

I can't really make heads or tails of this, it's still fairly complicated and I'm just not invested enough in it to read everything with a fine toothed comb. What I want to know is, will the sync (not async/await) methods be available on Linux on .NET Core? We've been struggling with that, the move to async/await is a major rewrite of our legacy application codebase and for what we do Mono has been a constant thorn in our side. In an ideal world the old sync APIs would just work and we'd be able to move forward with .NET Core as it stabilizes and get off Mono without a major rewrite.

edgyswingset 10y ago
Seems pretty simple to me. * Almost every .NET API will be in the standard library and thus will be cross-platform * Terrible APIs that they should have never created will be available as packages * Stuff that's platform-specific runs only on those platforms * Every API is listed in this repo: https://github.com/dotnet/standard https://github.com/dotnet/standard I got that from reading the TL;DR and skimming the rest of the post
mellinoe 10y ago
> What I want to know is, will the sync (not async/await) methods be available on Linux on .NET Core? Yes, they most likely will be. If you search through the reference assembly interfaces listed here, you should be able to tell whether the functionality you want will be available. https://github.com/dotnet/standard/tree/master/netstandard/ref https://github.com/dotnet/standard/tree/master/netstandard/r... For things like legacy synchronous or Begin/End async methods, we are more or less adding them wholesale to the standard. If something like that is still missing, then it's most likely an accidental omission rather than a conscious removal. (I work on .NET at Microsoft).
- bmurphy1976 10y ago
  I don't see anything for WebRequest in the referenced repository, but thanks for responding. I'm more hopeful than I've been since we found out .NET Core was async/await only. Migrating to async/await is very close to a complete rewrite for our codebase. We're not interested in it because it's such a big undertaking, and if we're forced to we might as well consider options other than .NET. My preference would of course be to leave things that work as-is and get on with the more important aspects of running our business.
  - dsp1234 10y ago
    WebRequest isn't present in .net core (afaik). It's replaced by System.Net.Http.HttpClient
  - taspeotis 10y ago
    I have been grafting asynchronous support into my codebase by a) writing new code with it and b) using AsyncContext [1] to run asynchronous stuff synchronously. The performance:lines of code ratio you can get with async is quite high. Using ADO.NET you can run mutually exclusive queries in parallel for up-to a 2x speedup (depending on what the queries need to do): using (var connection1 = ...) using (var connection2 = ...) { var getSomething1Task = GetSomething1Async(connection1, ..., cancellationToken); var getSomething2Task = GetSomething2Async(connection2, ..., cancellationToken); await Task.WhenAll(getSomething1Task, getSomething2Task); // now aggregate results from 1 and 2 } And it's more or less the same lines of code you'd need for the synchronous version. [1] http://stackoverflow.com/a/9343733/242520 http://stackoverflow.com/a/9343733/242520
    - tychuz 10y ago
      Yes, multithreading is stupidly easy nowadays. I also use Parallel.ForEach and sometimes .AsParallel() - changing "header" of foreach/for cycle is easy peasy and performance gains are instant. :)
  - mellinoe 10y ago
    If you look at this file, you should find the definitions for WebRequest and subclasses. It looks like the synchronous overloads you are looking for are there, but I'm not sure exactly which ones you want. Regardless, they should be there and if they aren't, it's most likely an accidental omission. https://github.com/dotnet/standard/blob/master/netstandard/ref/System.cs#L5834 https://github.com/dotnet/standard/blob/master/netstandard/r... I think that GitHub is either having trouble with how large some of these files are, or just hasn't indexed them yet, since they aren't showing up in the repo search.
  - tychuz 10y ago
    How come? So GetFoo() is replaced by GetFooAsync(), so just mass rename GetFoo() to GetFooAsync().Result and the end result will be the same... Unlike in JavaScript, async stuff is optional in C#, so block threads to your heart's content with .Result, it will behave like old sync methods...
terrajobst 10y ago
> What I want to know is, will the sync (not async/await) methods be available on Linux on .NET Core? Yes. > In an ideal world the old sync APIs would just work and we'd be able to move forward with .NET Core as it stabilizes and get off Mono without a major rewrite. Yes, being able to move forward with existing code is the primary reason they were added to .NET Standard.

edgyswingset 10y ago

Seems pretty simple to me. * Almost every .NET API will be in the standard library and thus will be cross-platform * Terrible APIs that they should have never created will be available as packages * Stuff that's platform-specific runs only on those platforms * Every API is listed in this repo: https://github.com/dotnet/standard https://github.com/dotnet/standard I got that from reading the TL;DR and skimming the rest of the post

mellinoe 10y ago

> What I want to know is, will the sync (not async/await) methods be available on Linux on .NET Core? Yes, they most likely will be. If you search through the reference assembly interfaces listed here, you should be able to tell whether the functionality you want will be available. https://github.com/dotnet/standard/tree/master/netstandard/ref https://github.com/dotnet/standard/tree/master/netstandard/r... For things like legacy synchronous or Begin/End async methods, we are more or less adding them wholesale to the standard. If something like that is still missing, then it's most likely an accidental omission rather than a conscious removal. (I work on .NET at Microsoft).

bmurphy1976 10y ago
I don't see anything for WebRequest in the referenced repository, but thanks for responding. I'm more hopeful than I've been since we found out .NET Core was async/await only. Migrating to async/await is very close to a complete rewrite for our codebase. We're not interested in it because it's such a big undertaking, and if we're forced to we might as well consider options other than .NET. My preference would of course be to leave things that work as-is and get on with the more important aspects of running our business.
- dsp1234 10y ago
  WebRequest isn't present in .net core (afaik). It's replaced by System.Net.Http.HttpClient
- taspeotis 10y ago
  I have been grafting asynchronous support into my codebase by a) writing new code with it and b) using AsyncContext [1] to run asynchronous stuff synchronously. The performance:lines of code ratio you can get with async is quite high. Using ADO.NET you can run mutually exclusive queries in parallel for up-to a 2x speedup (depending on what the queries need to do): using (var connection1 = ...) using (var connection2 = ...) { var getSomething1Task = GetSomething1Async(connection1, ..., cancellationToken); var getSomething2Task = GetSomething2Async(connection2, ..., cancellationToken); await Task.WhenAll(getSomething1Task, getSomething2Task); // now aggregate results from 1 and 2 } And it's more or less the same lines of code you'd need for the synchronous version. [1] http://stackoverflow.com/a/9343733/242520 http://stackoverflow.com/a/9343733/242520
  - tychuz 10y ago
    Yes, multithreading is stupidly easy nowadays. I also use Parallel.ForEach and sometimes .AsParallel() - changing "header" of foreach/for cycle is easy peasy and performance gains are instant. :)
- mellinoe 10y ago
  If you look at this file, you should find the definitions for WebRequest and subclasses. It looks like the synchronous overloads you are looking for are there, but I'm not sure exactly which ones you want. Regardless, they should be there and if they aren't, it's most likely an accidental omission. https://github.com/dotnet/standard/blob/master/netstandard/ref/System.cs#L5834 https://github.com/dotnet/standard/blob/master/netstandard/r... I think that GitHub is either having trouble with how large some of these files are, or just hasn't indexed them yet, since they aren't showing up in the repo search.
- tychuz 10y ago
  How come? So GetFoo() is replaced by GetFooAsync(), so just mass rename GetFoo() to GetFooAsync().Result and the end result will be the same... Unlike in JavaScript, async stuff is optional in C#, so block threads to your heart's content with .Result, it will behave like old sync methods...

terrajobst 10y ago

> What I want to know is, will the sync (not async/await) methods be available on Linux on .NET Core? Yes. > In an ideal world the old sync APIs would just work and we'd be able to move forward with .NET Core as it stabilizes and get off Mono without a major rewrite. Yes, being able to move forward with existing code is the primary reason they were added to .NET Standard.