Just be safe, let's not wait until other part of the code saves the
session, and let's do it right here on the spot, where we know it
changes.
@Laituex was having a ErrCode=32 'msg_seqno too low' problem and this
is the second thing we suspected to be the culprit, because if there's
any issue (e.g. exception) that makes the session not be saved after
the sequence got incremented, then an old sequence would be used the
next time upon loading an old session file.
(Backported from 1b06473108)
Even if you're not supposed to use multiple threads with TLSharp,
it might be worth it to try to make this sequence increment in
a thread-safe way. Race conditions are always bad even if you know
you are not supposed to use something in a certain way...
@Laituex was having a ErrCode=32 'msg_seqno too low' problem and this
is the first thing we looked at (even if he swore that he was not
using different threads to access the telegram network).
(Backported from 881bdd27a5 )
# Conflicts:
# src/TgSharp.Core/Session.cs
The reason for such a hack when runing in CI is because we
need to make sure we're using higher sequence numbers than
any previous times (and even previous runs of the test suite).
And we run 1 test only for now, later we will enable more.
Other notes:
The trick to extract secrets to files was taken from:
https://stackoverflow.com/a/59482124/544947
The binary-to-text encoding/decoding was taken from:
https://stackoverflow.com/a/42725926/544947
The way to add defines to DefineConstants for MSBuild:
https://stackoverflow.com/a/5053070/544947
Now that we have removed the only VS-specific project [1],
we can make all pipelines of all OSs consistent, building
the solution instead of a specific project.
[1] 90e16c1b1e
In "TLObject.Serialize() -> Serialize(BinaryWriter br) -> SerializeBody"
code path, constructor get written two times instead of once, which
since this code path is currently unused and it's only provided for
completeness, It's undetectable while testing.
Now that we have diverged from TLSharp[1], the new pre-release
versions pushed to nuget have different API and slightly
different behaviour so we want them to be marked as newer.
[1] since 4d09ac711d
Somehow for the previous commit hash, which had only numbers in its
short version (0122072), nuget failed with:
Run $date = get-date -format "yyyyMMdd-HHmm"
Attempting to build package from 'TgSharp.Core.csproj'.
Error NU5010: Version string specified for package reference '0.1.0-date.20200414-0908.git.0122072' is invalid.
File does not exist (TgSharp.0.1.0-date.20200414-0908.git.0122072.nupkg).
Now we remove the "." after "date" and "git" and use double-dash
to separate initial version from the sub-version.
