This updates all projects to target .NET Framework 4.7.1. The
TencentCOS and Tardigrade backends depend on .NET Standard 2.0. When a
.NET Framework prior to 4.7.1 is targeted, the system cannot be sure
that all the dependencies exist, so it copies all dependent assemblies
to the output directory. This causes many assemblies from the System
namespace to become bundled in the release.
https://stackoverflow.com/a/48875007
We had previously attempted to make individual projects target 4.7.1
(see pull request #4242), but this can cause compatibility issues when
4.6.2 projects depend on 4.7.1. projects.
This will require Mono 5.10.0 or greater (previously, we required 5.0.0
or greater).
https://www.mono-project.com/docs/about-mono/releases/5.10.0/#class-libraries
This fixes issue #4234.
In the current setup, the response stream is parsed by the JSON decoder, which throws an exception due to reading a non-json formatted error message.
The reported exception simply states that the first character on the first line was not valid json, which is true, but does not help diagnose the problem.
In many cases this is a human readable message, such as "over quota", "permission denied", etc.
This update adds a stream that keeps the first 2kb of the response in an internal buffer, which can then be printed in case the JSON parsing fails.
Most of the added code is just simple redirects for calling the base stream in the peeking stream.
The HttpClient.GetAsync method throws an OperationCanceledException when
the timeout is exceeded. In order to provide a more informative
exception, we will detect this case and throw a TimeoutException
instead.
This is related to issue #3772.
- no code changes except those noted below
- projects upgrade to 4.6.2
- wixinstaller project upgraded automatically by VisualStudio
- wixinstaller updated to require 4.6.2
- Library.Encryption changed to Standard2.0 so accommodate update to SharpAesCrypt
The HttpClient.SendAsync method throws an OperationCanceledException
when the timeout is exceeded. In order to provide a more informative
exception, we will detect this case and throw a TimeoutException
instead. This will also allow the BackendUploader to differentiate
between cancellations requested by the user and those generated by
an HTTP timeout.
Previously, a ThreadAbortException or OperationCanceledException would
be rethrown in the BackendUploader.DoWithRetry method. However, the
modifications made in revision 61f511c087
from pull request #3684 appear to have let this case slip through.
See the following links for more information:
https://stackoverflow.com/questions/10547895/how-can-i-tell-when-httpclient-has-timed-outhttps://thomaslevesque.com/2018/02/25/better-timeout-handling-with-httpclient
This addresses issue #3772.
For some reason, when using HttpWebRequest.GetRequestStreamAsync, the
Amazon Cloud Drive and Box backends would fail when attempting to upload
larger amounts of data (these are the only backends that use the
PostMultipartAsync method).
This fixes issue #3756.
The previous implementations resulted in an overload being hidden by one
without a default parameter, making it unclear which method was being
called. For example, consider the following signatures:
public MultipartItem(string content, string contenttype = null, string name = null, string filename = null)
public MultipartItem(string contenttype, string name = null, string filename = null)
From https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/named-and-optional-arguments,
> If two candidates are judged to be equally good, preference goes to a
> candidate that does not have optional parameters for which arguments
> were omitted in the call. This is a consequence of a general preference
> in overload resolution for candidates that have fewer parameters.
When the code following the await can be executed on any thread, it's
recommended to use ConfigureAwait(false) to avoid unnecessary context
switching and potential deadlocks.
This class extends HttpClient and uses an OAuthHttpMessageHandler under the covers to automatically authenticate requests.
Additionally, it automatically respects the global HttpContextSettings for overall timeout, read/write timeout, and SSL certificate validation.
(BufferRequests isn't currently handled, as HttpClient doesn't seem to easily expose that flag, and as of .NET 4.5, seems to not buffer by default.)
This class implements the abstract HttpMessageHandler class (mostly via the default HttpClientHandler implementation).
This abstract class is used by System.Net.Http.HttpClient as the underlying HTTP mechanism, and in this particular case is used to automatically add an authorization header to each request.
It also provides a method for marking a request as one that should not be authenticated.
These parameters weren't being used in the method body, or being passed in by any callers (it looks like a copy / paste error when a previous method was converted into this one)
These are replaced with a new optional parameter (method) which allows the caller to request a custom HTTP method to be used.
Using strong-named assemblies can cause difficulties with the GNU LGPL
license, which allows for one to recombine or relink their application
with modified versions of the code. While one solution is to share the
private key so that people can sign the assemblies themselves, this
would break the trust that is expected from signed assemblies. For now,
the easiest fix is to simply not sign the assemblies. Note that by
doing so, we prevent the code from being referenced from other signed
assemblies.
This also fixes an issue introduced in revision ba94d36a80 ("Added
auto-update for WindowsService and Service."), where the WindowsService
project (signed) referenced the AutoUpdater project (not signed).
We also removed instances of <SignAssembly>false</SignAssembly> to be
consistent with newly created .csproj files that do not contain the
SignAssembly element.
This was motivated by the discussion in issue #2814.
Kenneth Hsu