fixed issue #40 regarding partial streams

[Ralf1108]

No description provided.

[Ralf1108]

All tests are green and the PR Validation is wrong?
Can somebody give me a hint?
The error output is just:

Test Run Successful.
Total tests: 163
Passed: 162
Skipped: 1
Total time: 3.5337 Seconds
Running build failed.

1. Fake.UnitTestCommon+FailedTestsException: xUnit2 reported an error (Error Code 1)

---

at [email protected](String m) in D:\a\1\s\build.fsx:line 82
at Microsoft.FSharp.Core.OptionModule.Iterate[T](FSharpFunc2 action, FSharpOption1 option)
at FSI_0005.Build.ResultHandling.failBuildIfXUnitReportedError@86.Invoke(FSharpOption1 option) in D:\a\1\s\build.fsx:line 86 at Microsoft.FSharp.Collections.SeqModule.Iterate[T](FSharpFunc2 action, IEnumerable1 source) at [email protected](Unit _arg1) in D:\a\1\s\build.fsx:line 108 at Fake.TargetHelper.runSingleTarget(TargetTemplate1 target) in C:\code\fake\src\app\FakeLib\TargetHelper.fs:line 626
##[error]Process completed with exit code 42.

[Aaronontheweb]

Added @Arkatufus to this issue

[Arkatufus]

The problem is with the current dotnet compiler for netcoreapp2.1, it requires a very arbitrary version of SDK to be installed, and it depends on the (most probably) msbuild installation.
It insisted on using 2.1.21 on my machine, but insisted on using 2.1.13 in azure pipelines.
The accepted solution is to drop testing for netcoreapp2.1.

[Aaronontheweb]

Tests are passing now - just need to review. @Arkatufus do you want to take it or should I do it?-

[Arkatufus]

I'm doing it right now

[Arkatufus]

@Aaronontheweb I will need your input on this.

[Arkatufus]

The BinaryReader class guarantees any primitive bytes read for up to 16 bytes in length, ie. it will throw an unexpected EOF exception if the stream is interrupted mid-read. We can wrap all primitive reads with a BinaryReader to prevent the original issue from happening on primitive reads.

Our biggest concern is actually the multi-byte reads on the stream, such as arrays, strings, etc. We might need a guard on these reads, but I couldn't decide whether we should throw on partial fail reads or silently fail it.

[Aaronontheweb]

@Arkatufus I'll need to revisit the issue - if this is a partial read issue then that might be the responsibility of the framing system to solve it, rather than something the serializer needs to handle.

[Arkatufus]

I guess it really depends on type of deserialization is currently happening? We only need to guard on atomic primitive reads, but not on unknown length reads? if that is the case, then simply wrapping all Stream.Read with BinaryReader will fix this issue, at a cost.
Deserialize throughput will suffer a bit, especially on messages with a lot of reads.

[Aaronontheweb]

Need to handle the 0 bytes received case, but otherwise this PR looks good

[Ralf1108]

added default behavior to throw an EOF exception.

If the use case for useful partial reads comes up a flag to swallow the exception could be added.

[Arkatufus]

Thank you for the PR 👍