Ошибка при установке .Net Core на виртуальной машине Ubuntu: сбой восстановления dotnet в CurlHandler.SetProxyOptions()

На виртуальной машине Ubuntu 14.04 VMWare простые инструкции по адресу: [https://dotnet.github.io/getting-started/][1] работал нормально до следующего шага:

восстановление дотнета

Вот стек вызовов, который генерирует исключение:

System.ArgumentException: The value cannot be null or empty.   
Parameter name: UserName 
at System.Net.Http.CurlHandler.EasyRequest.SetProxyOptions(Uri requestUri) 
at System.Net.Http.CurlHandler.EasyRequest.InitializeCurl() 
at System.Net.Http.CurlHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)

at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)  
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()   
at Microsoft.Dnx.Tooling.Restore.NuGet.HttpSource.<GetAsync>d__11.MoveNext() 
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
at System.Runtime.CompilerServices.TaskAwaiter1.GetResult() 
at Microsoft.Dnx.Tooling.Restore.NuGet.NuGetv2Feed.<FindPackagesByIdAsyncCore>d__25.MoveNext()

at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)    
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()  
at Microsoft.Dnx.Tooling.RemoteWalkProvider.<FindLibrary>d__6.MoveNext() 
... 
at Microsoft.Dnx.Tooling.RestoreCommand.<Execute>d__68.MoveNext()

curl http://www.google.com

работает нормально, поэтому прокси для curl настроен правильно (/etc/environment содержит определения http_proxy="...")

У меня нигде нет настроенных учетных данных веб-прокси, поэтому неясно, почему nuget или RestoreCommand настраивают завиток с недопустимыми «пустыми» учетными данными.

Если nuget оставит учетные данные, null curl должен работать нормально, как и в командной строке, поскольку SetProxyOptions() отлично обрабатывает этот случай:

NetworkCredential credential = CurlHandler.GetCredentials(this._handler.Proxy.Credentials, this._requestMessage.RequestUri).get_Key();
if (credential != null)

ubuntu .net curl nuget coreclr
person Roger    schedule 15.12.2015    source источник
comment
@downvoters, пожалуйста, объясните...   -  person David    schedule 16.12.2015

Ответы (2)


arrow_upward
2
arrow_downward

Похоже, это дефект инструментов dotnet dnx, но в моем случае мне удалось обойти этот дефект. Я ожидаю, что RTM сделает исправление, так как это была RC-сборка ядра dot net.

Конструктор Nuget.HttpSource назначает учетные данные следующим образом, когда переменная среды «http_proxy» имеет простой формат (не имя пользователя):

UriBuilder builder = new UriBuilder(environmentVariable); 
WebProxy proxy = new WebProxy(environmentVariable); 
if (string.IsNullOrEmpty(builder.UserName)) 
{ 
   proxy.Credentials = CredentialCache.DefaultCredentials; 
}

DefaultCredentials установлен на неизменяемый набор пустых учетных данных:

SystemNetworkCredential.s_defaultCredential = new SystemNetworkCredential();

private SystemNetworkCredential() : base(string.Empty, string.Empty, string.Empty) {}

Поскольку SetProxyOptions() проверяет учетные данные, используя:

if (credential != null)
{
   if (string.IsNullOrEmpty(credential.UserName))
      throw ...

И имя пользователя пусто, оно всегда будет вызывать исключение.

Если бы вместо этого нужно было проверить, используя:

if (credential != null && !string.IsNullOrEmpty(credential.UserName))
   // do cred work

Тогда все было бы хорошо. Нулевые учетные данные или учетные данные по умолчанию (например, SystemDefaultCredentials, которые неизменно пусты) будут рассматриваться как «отсутствие учетных данных».

В противном случае Microsoft может изменить инструмент DNX, чтобы оставить учетные данные нулевыми вместо использования SystemDefaultCredentials. Это простой случай, когда вызывающая и вызываемая стороны не согласны с протоколом для указания отсутствия учетных данных (нулевая ссылка или ссылка с пустыми строками).

В моем случае обходной путь, который я использовал, заключался в том, чтобы заполнить фиктивные учетные данные, чтобы инструмент dnx не выдал ошибку. К счастью, мой прокси-сервер не жаловался на нежелательные и недействительные учетные данные.

person Roger    schedule 16.12.2015
comment
Я столкнулся с этой проблемой с образом Docker microsoft/aspnet:1.0.0-rc1-update1-coreclr. Ваш обходной путь помог: dnu restore -p http://user:[email protected]:12345 - person Blake Mitchell; 27.03.2016

arrow_upward
0
arrow_downward

Мне помогает использование аутентифицированного прокси: RUN dnu restore -p http://user:[email protected]. Я создаю образ From:microsoft/aspnet:1.0.0-rc1-final-coreclr

person xstabel    schedule 05.08.2016