> 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/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).

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.

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/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.

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

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. :)

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...

WebRequest isn't present in .net core (afaik). It's replaced by System.Net.Http.HttpClient

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

I got that from reading the TL;DR and skimming the rest of the post

> 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.