Because we might use dependencies soon that require this framework.
And anyway these days the .NET world is mostly a hybrid between
.NETStandard/.NETCore libs and .NET4.6 ones, not older than that.
WARNING: NU5118: File 'D:\a\TLSharp\TLSharp\TLSharp.Core\bin\Debug\TLSharp.Core.dll' is not added because the package already contains file 'lib\net45\TLSharp.Core.dll'
Added CancellationToken with default value to all async methods in TLSharp.Core
Added ConfigureAwait(false) to all async methods in TLSharp.Core
SendRequestAsync replaced to SendAuthenticatedRequestAsync in methods that need auth
Private modifier in SendAuthenticatedRequestAsync changed to internal
Based on PR created by @IaRuslan
Added methods for working with usernames:
Check username (Validates a username and checks availability)
Update username (Changes username for the current user)
Now user can set directory to store sessions somewhere else
other than the folder where the program's executable is.
(Based on patch from Felony <onyfel@gmail.com> contributed
in https://github.com/sochix/TLSharp/pull/874 )
People are reporting that under some circumstances, an infinite
loop could happen when TLSharp tries to handle a reconnection to
a different DC, if the DC instructed to be used is the same as
the one that was used in the last connection.
Not sure how could this happen (although the analysis present in
this github issue [1] might help understand it), but this commit
helps to make TLSharp fail fast (with an exception) instead of an
infinite loop from now on, which will help avoiding people file
issues such as [2] and [3] and instead maybe file a proper bug
report easier to understand, to try to fix the underlying root
cause.
[1] https://github.com/sochix/TLSharp/issues/719
[2] https://github.com/sochix/TLSharp/issues/803
[3] https://github.com/sochix/TLSharp/issues/839
It wasn't being used internally, and the use-case to be used
externally is too intricated. There's already a way to change
the handler at contructor time[1] so that should be enough
customization.
[1] 48077961ae
If a method that returns bool is never returning false,
it's essentially not giving any information at all, which
means that it should return void. This will help the
consumers of this API to stop thinking that the result
of this function means if the connection was succesful
(which it is, actually, but it was never returning false
because if there's any problem connecting, the result would
be an exception instead).
The method IsPhoneRegisteredAsync() was calling
RequestWithDcMigration() which was the real method
that made use of the _sender field, so we can move
the null check to there.
This will also help track down possible NullReferenceExceptions
that could happen when other callers of this method
arrive with a bad _sender, which might aid us trying
to fix#706.
Load() method in ISessionStore requires public constructor of class Session in some cases.
E.g., loading session from a db or a key-value store, manual loading from text-file, JSON/XML and so on.
