Closed buvinghausen closed 3 years ago
The target framework plan looks good to me.
Move namespace to System.Threading.Tasks so people can leverage the code without having to import our specific namespace.
This is a breaking change both for recompiling (all projects with using TaskTupleAwaiter;
get build errors) and for swapping the binary at runtime without recompiling (e.g. when this package is transitively referenced on more than one path and the SDK picks a winner). I'm okay with this but this forces the version to 2.0.0.
Also, what do you think about not using a namespace? It would seem kind of odd to me that I would not need to import the System.Threading.Tasks namespace in order to do await FooAsync(); await BarAsync();
but then I would need to import it to switch to await (FooAsync(), BarAsync());
Perhaps this will become a moot point with the .NET 6 SDK adding default global usings when using C# 10+.
@jnm2 sorry for the late response but with RC1 dropping today I was probably going to release to nuget in concert with it.
I was definitely going to version it as 2.0
My assumption is/was that you would only be using this in async functions that return either Task or Task<T> which are both in the Sytem.Threading.Tasks namespace ergo you would have already imported it.
Yes as far as the C# 10+ default global namespace bit it would become a moot point for people who have moved to the latest release.
@jnm2 this has been published pending indexing and validation
Nice!
Proposed changes:
Drop .NET 2.1 test support as it has officially reached EOL
Bump .NET Framework minimum version to 4.6.2 reason: .NET Framework 4.5.2, 4.6, 4.6.1 will reach End of Support on April 26, 2022
Add .NET 6.0 test support and update once more when RTM drops in November.
Move namespace to System.Threading.Tasks so people can leverage the code without having to import our specific namespace.
Update nuget API key as has expired
@jnm2 let me know if you're opposed to any of these. I doubt you are but you know what they say about assumptions.