tunnelvisionlabs / dotnet-threading Goto Github PK

The Task.WhenAll method is not available prior to .NET 4.5. A new utility method would be useful to provide this functionality from .NET 3.5 onward.

Since Task instances can be disposed, it is possible for a misuse of a cached Task returned by a CompletedTask method or property to cause cascading failures across an application relying on this feature.

Attempting to install this library in the Flurl.Http.PCL project produces the following output:

Installing 'Rackspace.Threading 1.0.0'.
Successfully installed 'Rackspace.Threading 1.0.0'.
Adding 'Rackspace.Threading 1.0.0' to Flurl.Http.PCL.
Uninstalling 'Rackspace.Threading 1.0.0'.
Successfully uninstalled 'Rackspace.Threading 1.0.0'.
Install failed. Rolling back...
Could not install package 'Rackspace.Threading 1.0.0'. You are trying to install this package into a project that targets 'portable-net45+sl50+win+wpa81+wp80', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

Following the implementation of #67, all builds of this library except for the .NET 3.5 build will be forwards-binary-compatible. Only two strong name keys are needed:

1. One for the .NET 3.5 build
2. One for all other builds

Came across this project. I am wondering why it exists though. Is it for people who don't want to upgrade the version of the .NET framework that they are targeting?

In the .NET 4.0 library, the signature of IProgress<T> should be IProgress<in T>.

Currently the CancellationTokenSourceExtensions class is omitted from builds targeting versions of the .NET Framework which include the CancellationTokenSource.CancelAfter method. To ensure the binary compatibility promise described in #69 holds, this class should be included in all releases; the implementation for .NET 4.5 can simply delegate the call to CancellationTokenSource.CancelAfter.

Consider providing overloads for TaskBlocks.Using where the body function returns a TResult value instead of a Task<TResult>.

Currently, the Task Building Block methods Using and While are part of the CoreTaskExtensions class. This is confusing because it combines the functionality for Extension Methods for Task Continuations and for Task Building Blocks, which are logically separate features as described in the User Guide.

The Task Building Block methods should be refactored to their own class, the name of which is yet to be determined.

In #101, the ID of the NuGet package was changed. To facilitate upgrading from Rackspace.Threading to TunnelVisionLabs.Threading, a metadata-only Rackspace.Threading v2.0.0 should be published which includes a dependency on TunnelVisionLabs.Threading.

Prior to .NET 4.5, failing to access the Exception property of a faulted task would result in the process being terminated. It's essential that users running code in these environments be certain all faulted tasks will be properly observed.

In most cases, this library already works well because a key objective is properly propagating the state of an antecedent task to a result task. However, there are several cases where problems can occur:

1. If an antecedent task enters the faulted state, but the final result is propagated from a continuation task which ignores the antecedent, the antecedent needs to at least be observed.
2. The implementation of TaskBlocks.While has several cases where the Finally extension method is used to transfer task state. If the antecedent to Finally is faulted, then the result of Finally will also enter the faulted state regardless of the implementation of the Finally action.

The test code for this project should stand up a local web service for the WebRequestExtensions tests, rather than rely on http://httpbin.org. In addition to allowing offline builds (and testing), this feature will improve the reliability of tests which include timeouts.

The PowerShell script to push a package to NuGet should verify that the contained assemblies use the expected publicKeyToken value in their strong names, to ensure the assembly versioning expectations are met.

The Task.Delay method is not available prior to .NET 4.5. A new utility method would be useful to provide this functionality from .NET 3.5 onward.

Prerelease versions of the library should not use the same strong name keys as final releases. This became apparent when solving a bug in another library which uses a similar versioning model to this library. In that case, a particular extension to Visual Studio included a prerelease build of the library. When used with other extensions, Visual Studio would occasionally load the prerelease library in place of the final release, causing extension which (properly) relied on the final release to not work properly.

Once implemented, this functionality will also address the final major concern blocking the inclusion of project-specific strong name keys within the repository itself.

The NET40PLUS builds should include the following:

[assembly: TypeForwardedTo(typeof(System.IProgress<>))]

Despite the fact that strong name keys are now in source control (#77), the projects still reference the Rackspace.KeyReporting NuGet package. This reference can be removed.

Currently the StreamExtensions class is omitted from builds targeting certain versions of the .NET Framework. To ensure the binary compatibility promise described in #69 holds, this class should be included in all releases.

The library currently includes several Finally extension methods. It would be useful to include Catch<TException> methods as well.

• If an antecedent task finishes in the RanToCompletion state, the Catch handlers are not evaluated.
• If the Task<TResult>.Exception.InnerExceptions property contains exactly one exception, it is unwrapped prior to executing the handlers. Otherwise, the AggregateException is not unwrapped prior to exception handling.

When the 1.0.0-beta001 package is installed in a project targeting .NET 4.0 or newer, a dependency is added to the TaskParallelLibrary package. This dependency should only be installed when the project targets .NET 3.5.

The IProgress<T> type is not currently a drop-in replacement for System.IProgress<T>, and values implementing one of these do not implement the other. By using the IProgress<T> type defined in .NET 4.5, or in Microsoft.Bcl for .NET 4.0, all versions of this library except the .NET 3.5 target will use an IProgress<T> interface which is equivalent to the interface defined by Microsoft.

Currently the WebRequestExtensions class is omitted from certain builds. To ensure the binary compatibility promise described in #69 holds, this class should be included in all releases.

The Task.WhenAny method is not available prior to .NET 4.5. A new utility method would be useful to provide this functionality from .NET 3.5 onward.

A message like the follow would be useful when strong name keys have not been generated for a build.

Strong name key not found. Run "sn -k {filename}" to generate the key in "{absolute directory}".

If implemented in a separate .targets file, this feature could be used in multiple projects, and perhaps even distributed as its own NuGet package.

The using task building block would be more useful if it supported the IAsyncDisposable interface proposed in the following thread:

IAsyncDisposable, using statements, and async/await

Note that since the IAsyncDisposable interface does not currently exist as part of the .NET Framework, it would need to be provided as part of this library.

http://stackoverflow.com/questions/25083033/differentiating-assemblies-by-publickeytoken-alone