We had a startTask we would await in DisposeAsync and channel completion continuation. This task would be initially set to a completed task and then once StartAsync was invoked it would be replaced with the actual task representing StartAsyncInternal. However if a transport failed immediately after starting the channel completion continuation could have been called before the StartAsyncInternal method completed. In this case we would await the inital completed task and then very likely would fail trying to await _receiveLoop task because it wouldn't necessarily be set.
The fix is to use TaskCompletionSource so we don't try to swap tasks. We need to do some additional state checks because:
- the TaskCompletionSource task may never be completed (e.g. DisposeAsync is being called without starting the connection)
- TaskCompletionSource allows setting the result only once and we should not return its task more than once (e.g. calling StartAsync after connection was successfully started and stopped)
Fixes#304
Fixing a race where removing the last message from the channel would trigger draining the event queue (in channel Completion continuation) which would prevent from raising the Received event for the very message that was read from the channel.
- Creating an MSBuild project for the TS client
- Adding project references to the TS client project from projects that need the client - (ensures the correct targets dependency graph and prevents building the client multiple times and related races)
- Removing gulp tasks from individual projects (allows containing npm only in the TS client source and node tests)
- Using incremental compilation to build the TS client only when inputs change (prevents building the client multiple times or when not needed at all)
- Removing `npm install` from all the projects (takes up to 10 seconds even if there is nothing to restore) - npm packages will still be installed when running full build (if needed) or need to be installed manually