Runtime: Нарушены правила безопасности наследования по типу: 'System.Net.Http.WebRequestHandler'. Производные типы должны либо соответствовать доступности безопасности базового типа, либо быть менее доступными.

Мне довелось взглянуть на это сегодня из другого отчета. / cc @ChadNedzlek

Похоже, это может быть связано с отсутствием атрибутов безопасности во внеполосном System.Net.Http.dll по сравнению с System.Net.Http.dll в папке входящих сообщений. Версия Inbox имеет AllowPartiallyTrustedCallers. То же самое и с почтовым ящиком System.Net.Http.WebRequest.dll. Это означает, что все обрабатывается как SecurityTransparent, если не указано иное.

В OOB System.Net.Http.dll отсутствует AllowParhibitedTrustedCallers, что делает все критичным для безопасности. Теперь, когда входящий WebRequest.dll загружает OOB System.Net.Http.dll, он нарушает правило безопасности, поскольку WebReqeuestHandler прозрачен, но HttpClientHandler, от которого он происходит, имеет решающее значение.

Моя репродукция:

1. Файл> новое настольное приложение
2. Свойства проекта> подпись> включить подпись строгого имени
3. Добавить ссылку на System.Net.Http.WebRequest
4. Установите System.Net.Http 4.1.0.
5. В основном просто вызовите new WebRequestHandler ();

ericstj прав, у меня здесь та же проблема. Это критическая проблема в System.Net.Http 4.1.0, которую необходимо исправить. Я не могу использовать эту библиотеку с .net4.6.1, потому что ей не хватает согласованности.

С этой проблемой очень сложно справиться, и, в частности, использование клиента Azure KeyVault болезненно для моей команды. Единственная безболезненная альтернатива - перейти на .NET 4.5.2, что неприемлемо.

Кроме того, описанного выше обходного пути недостаточно. Если вы хотите использовать NET 4.6.x, мы обнаружили, что для его надежной работы вам необходимо сделать следующее: отключить проверку зависимостей, понизить версию System.Net.Http, отредактировать CSPROJ и отключить автоматическое перенаправление привязки, изменить app.config и, как правило, очистить / выйти из VS / и перестроить, как я часто видел в использовании System.Net.Http, даже для тривиальных проектов. Вот процедура, которая надежно это исправляет.

1. Щелкните правой кнопкой мыши проект в Visual Studio и выберите «Управление пакетами NuGet».
2. Перейдите на вкладку Установленные.
3. Прокрутите вниз до SYSTEM.Net.Http, но не до Microsoft.Net.Http.
4. На правой панели, если Установлено не 4.0.0.0, установите Версия 4.0.0.0.
5. На правой панели установите для параметра Поведение зависимостей значение Игнорировать зависимости. Если вы НЕ сделаете этого, пакет Microsoft.IdentityModel.Clients.ActiveDirectory будет существенно понижен, что НЕ правильно.
6. Нажмите «Обновить» - эта кнопка действительно должна называться «Изменить на версию».
7. В окне предварительного просмотра убедитесь, что ТОЛЬКО указанное изменение - «Установка System.Net.Http». Если вы забыли правильно настроить поведение зависимостей, здесь будет указано дополнительное изменение.
8. Нажмите OK / Да / Я согласен в диалоговом окне подтверждения и дождитесь завершения обработки. По завершении в списке пакетов будут показаны два номера версии - галочка находится рядом с той, которая используется.
9. На вкладке «Установленный NuGet» выберите список для Microsoft.IdentityModel.Clients.ActiveDirectory.
10. На правой панели сведений установите для параметра Поведение зависимости значение «Игнорировать». Если вы этого не сделаете, любые последующие добавления NuGet завершатся ошибкой при выполнении проверки NuGet для этого пакета.
11. В Visual Studio выберите Файл | Сохранить все.
12. Откройте файл CSPROJ для этого проекта в текстовом редакторе.
13. В / Project / PropertyGroup * 1 (первый элемент PropertyGroup в Project) добавьте следующую строку или измените значение этого элемента, если он уже существует:
    <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>
14. Сохраните файл, затем перезагрузите проект в Visual Studio.
15. Откройте файл app.config для этого проекта.
16. Найдите строку для System.Net.Http и отредактируйте ее, чтобы перенаправить на 4.0.0.0 вместо 4.1.0.0. Итак, найдите это:

<dependentAssembly> 
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" /> 
</dependentAssembly> 

И измените его на это:

<dependentAssembly> 
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.0.0.0" /> 
</dependentAssembly> 

1. Восстановите проект. Если вы получаете исключение при запуске кода Azure Key Vault, один или несколько файлов * .config в bin / debug или аналогичных каталогах не были обновлены. Возможно, вам придется выйти из Visual Studio, чтобы очистить их и перестроить.

dluxfordhpf, спасибо, что уделили время объяснению, как вы с этим справились. Перенаправление на System.Net.Http 4.0 у меня сработало в .net4.6.1, но все еще очень сложно поддерживать (зависимость nuget). С нетерпением жду версии, которая это исправит.

Перенаправление может вызвать проблемы, если люди используют любой из новых API, добавленных в System.Net.Http 4.1.0.

в частности, делает использование клиента Azure KeyVault болезненным для моей команды

У @ChadNedzlek была та же проблема, и он смог ее обойти, передав HttpClient, который он создал сам, в конструктор KeyVaultClient. Если вы не используете WebRequestHandler, вы избежите проблемы.

НАПРИМЕР:

c# var handler = new HttpClientHandler(); // configure handler // eg: handler.ServerCertificateCustomValidationCallback = (message, cert, chain, errors) => errors == SslPolicyErrors.None; var client = new HttpClient(handler); var kvclient = new KeyVaultClient(async (authority, resource, scope) => "foo", client);

@davidsh Я думаю, вам нужно вернуть AllowPartiallyTrustedCallers в System.Net.Http.dll. / cc @morganbr

@dluxfordhpf Большое спасибо за шаги.
Это временно, и мы надеемся, что скоро все исправим, но все же я могу продолжить работу над проектом!

@terrajobst Это проблема с производством. Есть идеи, когда мы сможем исправить NuGet? Благодаря!

Просто столкнулся с этим сам. Было бы здорово, если бы мы не погрузились в ад зависимостей в .Net. Он идет туда.

РЕДАКТИРОВАТЬ: исправлено с предложением предыдущих комментариев использовать системный httpclient ??
new KeyVaultClient(GetAccessToken, new HttpClient(new HttpClientHandler()))
Кажется, я понял ...

Проблема только усугубляется, поскольку все больше и больше пакетов nuget от Microsoft зависят от последней версии System.Net.Http. Я, наверное, не единственный, кто постоянно обновляет свои пакеты Microsoft nuget до последней предварительной версии. Например, пакеты, которые больше не работают у меня в последней версии:

Microsoft.IdentityModel.Clients.ActiveDirectory
Microsoft.TeamFoundationServer.Client
Microsoft.VisualStudio.Services.Client.
....

Я до сих пор не понимаю, почему этот пакет все еще доступен. @terrajobst @coolcsh можно ли убрать / исправить этот пакет? Это ДЕЙСТВИТЕЛЬНО вызывает проблемы со сложной средой приложений. Потратил несколько часов на то, чтобы не дать вредоносному пакету проникнуть в сборку. Благодаря!

Мы рассматриваем привязку к System.Net.Http в NET Framework вместо этой сломанной штуки из NuGet. Я согласен, это нелепая проблема, и ее очень дорого решать, поскольку вы должны синхронизировать версии NuGet между проектами, предотвращать автоматические обновления привязки и исправлять / проверять файл app.config. Что меня удивляет, так это то, что это такая широко используемая сборка. Может быть, MS не особо заботится о KeyVault?

Он также используется слепком ActiveDirectory.

Я отменил ориентацию некоторых библиотек на .NET Standard из-за этой и других связанных с этим проблем, когда сломанные пакеты NuGet просто портят приложения, нацеленные на .NET Standard. Это прискорбное положение вещей.

Спасибо за подачу. Мы активно этим занимаемся. Оставайтесь в курсе.

Это стало для меня серьезной проблемой; мы используем множество собственных пакетов nuget внутри компании. И похоже, что nuget просто _не_ оставит эти bindingRedirect покое. Каждый раз, когда мы обновляем один из наших внутренних пакетов, он меняет перенаправление обратно на newVersion="4.1.0.0" . Есть ли способ помешать этому, или есть исправление на горизонте?

Обнаружено при запуске приложения через HTTPS, которое нормально работало через HTTP. Не уверен, есть ли другие существенные отличия.
У меня сработало обходное решение установки newversion="4.0.0.0" .

По-прежнему проблема в NETStandard 1.6.1. Почему?!

System.Net.Http 4.3.0 отсутствует. Кто-то пробовал?

@LoulG Да,

Я поговорил с @terrajobst в Твиттере, и он сказал, что это на самом деле большая проблема, и сейчас над этим работают около 10 человек. Я лично не уверен, почему они не извлекают версии этого пакета, отображающие проблему, так как я думал, что для этого и было управление пакетами. Но теперь мы можем подождать.

@LoulG здесь то же самое, я обновил все свои пакеты Nuget с выпуском .net core 1.1, и у меня возникла эта проблема

System.TypeLoadException: правила безопасности наследования нарушены типом: 'System.Net.Http.WebRequestHandler'. Производные типы должны либо соответствовать доступности безопасности базового типа, либо быть менее доступными.

Во-первых, я думаю, что это произошло из-за IdentityServer / IdentityServer3.AccessTokenValidation, но, прочитав эту проблему, я понял свою ситуацию t_t, я потратил несколько часов, чтобы попытаться ее решить.

РЕДАКТИРОВАТЬ :
О, МОЙ БОГ,
Обходной путь установки newversion = "4.0.0.0" тоже работал у меня

Я пытаюсь обновиться до 4.3, но такая же проблема: (((

такая же проблема здесь после обновления

Проблема все еще присутствует в 4.3.0.

@terrajobst, можете ли вы предоставить какие-либо обновления по этой проблеме или какое-либо дополнительное понимание более глубокой проблемы, на которую ссылается

По какой-либо причине это исправление работает локально, но при развертывании в облачной службе Azure ошибка сохраняется?

Иногда упаковка Azure может испортить ваши перенаправления привязки, попробуйте разархивировать cspkg и посмотреть, что на самом деле развертывается.

Вот версия System.Net.Http.dll

Я работаю над этим уже несколько дней. Был очень рад найти это исправление и плакал при развертывании в Azure.

А как насчет файла .config, содержащего перенаправления привязки для проекта? На самом деле я ожидаю, что он по-прежнему развернет сломанную версию сборки из-за того, что CopyLocal имеет значение true из пакета nuget, но перенаправление привязки должно гарантировать, что версия сборки сборки вместо этого загружается внутри виртуальной машины облачной службы.

Это!!! WTH?

<dependentAssembly> <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" /> </dependentAssembly>

Возвращаясь к моему проекту, я обнаружил, что файл web.config тоже вернулся. Придется забрать это утром снова. Спасибо за подсказки!

Я обнаружил, что если вы используете AutoGenerateBindingRedirects, а затем изменяете любой пакет nuget для проекта, он «исправляет» ваши ранее измененные вручную перенаправления обратно к неработающей версии. Очень неприятно.

Но отчасти проблема в том, что если вы НЕ используете AutoGenerateBindingRedirects при добавлении новых пакетов, вы также можете столкнуться с другими проблемами.

Я занимаюсь этой ерундой уже больше недели, пока мне нужно развернуть новую версию нашего приложения. Лучшее, что я могу предложить, - это выработать привычку проверять файл web.config при каждом развертывании.

Да, вам нужно отключить обновления привязки с помощью ручного редактирования в CSPROJ, а затем исправить перенаправления привязки .config, И перенастроить NuGet в графическом интерфейсе, чтобы НЕ обновлять зависимости, и ТОГДА все в порядке. Да, это крупный PITA, я удивлен, что он так долго не производился. Моя команда регулярно ругает это уже несколько месяцев.

К сожалению, следование приведенному выше по-прежнему исправляет только мою среду разработки, а не лазурный продукт. Я проверил последний файл pub, и файл web.config был правильно настроен вместе с моей dll, которая публикуется как версия, изображенная выше. К сожалению, мои проблемы касаются библиотеки поиска Azure, поэтому это исправление оказалось многообещающим. Есть еще какие-нибудь идеи? Немного потеряно. Спасибо за помощь.

Почему этому больше 2 месяцев? Это огромная проблема. Пожалуйста исправьте.

Это полностью вопрос остановки корабля, его абсолютно необходимо решить.

Ради бога, ребята, исправьте это уже. Это идиотизм.

@suprduprmn Я обновил и объединил все пакеты, а затем изменил это во всех файлах app.config и web.config:

<bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.0.0.0" />

Только после этого мое веб-приложение запустится в Azure и сможет выполнять https-вызовы в службы Azure, которые зависят от System.Net.Http. YMMV, но удачи.

И @terrajobst ... есть ли подходящее место, где я могу официально пожаловаться на игнорирование таких серьезных проблем? Беззаботные правила открытого исходного кода здесь не применяются. Это материал Microsoft Showstopper 101 примерно 1995 года. «Сообщество» никак не может помочь. Вы должны исправить это, и вам нужны инструменты архитектора и процесс, чтобы убедиться, что это перестает происходить. Я вижу подобные вещи в нескольких проектах Microsoft, и это абсолютно неприемлемо. Очевидно, что в тестировании есть огромные пробелы. Базовые сценарии просто не устанавливаются и не собираются чисто, не говоря уже о правильной работе во время выполнения.

Я хочу извиниться за XXXL, что нам потребовалось много времени, чтобы ответить на этот вопрос. С момента последнего ответа прошел 1 месяц, а вопрос открыт более 3 месяцев. Я согласен, что это неприемлемо для такой серьезной проблемы, как эта.

Этим утром мое внимание привлекли к этому вопросу, и я попытался провести исторические раскопки в течение последних нескольких часов. Хорошая новость заключается в том, что правильные люди изучают проблему в течение последних нескольких недель (возможно, даже дольше, я не проверял всю историю). К сожалению, решение очень сложное :( и поэтому у нас еще нет хорошего ответа или ETA (хотя это не оправдание отсутствия обновлений с нашей стороны).
Есть несколько возможных решений, но до сих пор не пришли к единому мнению даже эксперты, и у каждого из них есть свои недостатки.
На следующей неделе мы начнем ежедневную синхронизацию по этой проблеме, пытаясь найти решение проблемы как можно быстрее. Я буду публиковать обновления (надеюсь, с более подробной технической информацией), когда они будут у нас, по крайней мере, еженедельно.

К сожалению, это лучшее, что я могу сделать на данный момент (т.е. искренние извинения и заверения, что мы серьезно и будем относиться к этому серьезно и сделаем все возможное, чтобы исправить это как можно скорее). Если у кого-то есть альтернативные предложения, я все слышу.

@karelz Я бы не хотел отвлекать команду от фактического решения проблемы прямо сейчас, но лично я хотел бы услышать посмертный анализ основной причины этой проблемы и того, как она прошла через QA. Это вызвало большую головную боль, и я думаю, что прозрачность заслужит некоторое доверие.

@jahmai Понятно, меня это тоже интересует, но сначала я хочу сосредоточиться на решении. Затем мы сможем проанализировать, что произошло, почему и как предотвратить подобные инциденты в будущем.

Спасибо за ответ. Я думаю, что лучшим решением на данный момент является деактивация любого пакета, который не указывает на System.Net.Http 4.0.0. Есть как минимум 2 плохие версии пакета. Разве не в этом смысл в первую очередь распространять этот материал через NuGet?

обнимаю @ ms-team

Кроме того, чтобы вы знали, между этой проблемой проблемы с HttpClient настолько плохо спроектированы, проблемы вокруг Microsoft.Security.Owin.Jwt не соответствуют текущим зависимостям и состояние .NET Core ...

Сейчас невероятно разочаровывающее время - быть разработчиком .NET. Каждое развертывание теперь требует 30 минут проверки ссылок на привязку сборок, чтобы мои приложения не сломались в производственной среде. Это не та Microsoft, за которую я так долго отстаивал. Я люблю вас, ребята, и совсем не хочу быть резким ... Но мне кажется, что для восстановления качественного статус-кво нужна жесткая любовь.

Что нужно делать. Даже если это означает выпуск 4.3.1, который ссылается на старый пакет 4.0. Пожалуйста, сделай это поскорее.

Спасибо ребята. FWIW, если вам нужно внести критические изменения, сделайте это. Нам это не нравится, но мы живем с болью в течение нескольких месяцев, и теперь, когда мы знаем, что вы помолвлены, мы можем подождать еще пару, даже если нам придется внести некоторые изменения в API.

Здесь что-то не так. Я занимаюсь поставкой приложений C # уже 15 лет. По иронии судьбы, поскольку Microsoft поставляет абстракции более высокого уровня, я трачу все больше и больше времени на то, чтобы углубиться во внутренности, о которых раньше никогда не приходилось беспокоиться. ТЫ ДЕЛАЕШЬ ЭТО НЕПРАВИЛЬНО.

Я недостаточно умен, чтобы понять, почему сброс флагов доверия в этой библиотеке является огромным делом, и я не понимаю, почему у меня нет большего контроля над этим из моего приложения.

Если бы я хотел быть удивлен во время выполнения случайными ошибками, вызванными библиотекой и управлением пакетами, которые компилятор не улавливал, я бы написал свои приложения на Ruby.

Быстрое обновление:
На этой неделе мы встречались несколько раз. Мы продумали варианты и выяснили финансирование.
@CIPop работает над этой проблемой как с высшим приоритетом (работа передана от

Положение дел:

• Мы смогли воспроизвести оригинальную репродукцию
• Мы стремимся к решению [3] ниже - сосредоточив внимание на остающемся нерешенным вопросе, т.е. на проверке технической осуществимости варианта.
• Мы исследуем параллельное решение [2] ниже - исследуем его открытый вопрос, то есть оцениваем влияние решения на экосистему.

Описание проблемы

• Мы отправили System.Net.Http 4.3.0.0 «OOB» в июне.
  
  
  
  • Примечательный контент (для этого контекста): HttpCient, HttpClientHandler
  
  
  • Ценность для клиента: поддержка сертификатов, поддержка http2, стек WinHttp на рабочем столе
  
  
  • Все платформы, кроме Desktop, работают нормально - для Desktop поверхность API не имеет SecurityAttributes для кода PartialTrust (APTCA = AllowPartialTrustCodeAttribute)
  
  
  • На рабочем столе библиотека OOB переопределяет использование System.Net.Http 4.0.0.0, которое является частью платформы (и имеет APTCA).
  
  
• System.Net.WebRequestHandler 4.0.0.0 является частью рабочего стола
  
  
  
  • Это зависит от System.Net.Http и имеет APTCA, поэтому требует, чтобы System.Net.Http имел APTCA
  
  
  • Он использует внутренние типы из System.Net.Http (который имеет InternalsVisibleTo)
  
  
  • Это «скучный» устаревший тип, который нам не нужен в .NET Core.
  
  
• Существуют библиотеки (3+ пакетов NuGet и приложение ASP.NET Core на рабочем столе), которые будут (косвенно) предоставлять как OOB System.Net.Http 4.3.0.0, так и ссылку на System.Net.WebRequestHandler 4.0.0.0. Комбинация предотвращает запуск приложения.

Решения

1. [НЕ ДОПУСТИМО] Ручное перенаправление привязки - вручную для перехода на более раннюю версию приложения (через перенаправление привязки) System.Net.Http 4.3.0.0 до 4.0.0.0 - трудно понять, что / где, и это ручной шаг для каждого приложения
   
   
   
   • Примечание. Сегодня используется как «обходной путь»
   
   
2. [КАНДИДАТ] Отменить решение OOB - повторно отправить 4.3.1.0 как перенаправление на рабочий стол Inbox 4.0.0.0.
   
   
   
   • Обратная сторона: мы сломаем клиентов, которые зависят от новых функций.
   
   
   • Открытый вопрос: затронут ли WCF или другие библиотеки NuGet на рабочем столе?
   
   
3. [CANDIDATE] Добавьте атрибуты безопасности в System.Net.Http
   
   
   
   • Делайте это только для рабочего стола (используйте #if), не распространяйте его на другие пакеты (компилируйте по ссылке на рабочий стол), добавляйте тесты, применяющие его в будущем.
   
   
   • Оборотная сторона: некоторые свойства WebRequestHandler, специфичные для настольной реализации System.Net.Http, не будут работать (по дизайну, поскольку мы переключили реализацию)
   
   
   • Техническое примечание: методы Async должны быть SecurityTransparent (ограничение компилятора Roslyn), поэтому они не могут вызывать (SecurityCritical) PInvokes - для каждого такого вызова PInvoke должен быть метод оболочки SecuritySafeCritical (довольно уродливый, но простой)
   
   
   • Открытый вопрос: можем ли мы заставить внутренние зависимости WebRequestHandler работать с новой системой System.Net.Http на основе WinHttp?
   
   
4. [ОТКЛОНЕНО] OOB WebRequestHandler только на рабочем столе
   
   
   
   • Оборотная сторона: выталкивает проблему вверх по стеку (от этого зависит некоторая сборка APTCA)
   
   
   • Оборотная сторона: некоторые свойства WebRequestHandler, специфичные для настольной реализации System.Net.Http, не будут работать (по замыслу) - см. [3] выше
   
   
   • Оборотная сторона: каждый должен добавить зависимость или указать NuGet установить последнюю версию.
   
   
5. [CANDIDATE] Добавить System.Net.WebRequestHandler.dll в пакет NuGet System.Net.Http
   
   
   
   • 2 недостатка такие же, как в [4] выше:
     
     
     
     
     
     1. Оборотная сторона: выталкивает проблему вверх по стеку (от этого зависит некоторая сборка APTCA)
     
     
     
     2. Оборотная сторона: некоторые свойства WebRequestHandler, специфичные для настольной реализации System.Net.Http, не будут работать (по замыслу) - см. [3] выше
     
     
     
   
   

Спасибо за подробную информацию, мы ценим это.

Как насчет комбинации Варианта 2 и повторной отправки 4.3 как 5.0? Поскольку это было критическое изменение с технической точки зрения, вы также можете отправить OOB WebRequestHandler.dll для настольных ПК как v5.0. Это позволило бы вам повторно реализовать функциональность в WinHttp, отказаться от свойств, которые не отображаются, и дать всем возможность двигаться вперед так, как предполагалось в SemVer. Разработчикам также необходимо будет исправить свой код, но это не является неожиданностью для основного выпуска, и они также могут просто установить верхнюю границу своих пакетов, чтобы не включать 5.0.

Я имею в виду, у меня возникла идея отправить все группы пакетов фреймворка с одинаковыми номерами версий, но а) этот пес уже был облажался, когда вы, ребята, отправили все как 4.0 вместо того, чтобы следовать существующему управлению версиями рабочего стола, и б) фактическое управление версиями сборок уже повсеместно (пакет System.Security.Claims 4.3 включает в себя 4.0.2 dll, что очень раздражает при создании перенаправления привязки). Итак, ущерб уже нанесен.

dotnet / corefx # 3 кажется мне единственным реальным решением первопричины.

@robertmclaws Мы не думаем, что изменение версии изменит ситуацию. Большинство людей (владельцы приложений и библиотек) обычно просто «обновляют до последней» свои пакеты, им все равно, насколько изменилась версия (незначительная или основная). Так что разрушающий удар будет точно таким же.
Еще хуже то, что эффект «ломки» обнаружится только тогда, когда вы объедините несколько вещей. Вот почему эта проблема в первую очередь проскочила - у нас нет тестирования для этой комбинации (и я бы сказал, что это нормально - нельзя проверить все комбинации, но мы можем обсудить это позже после вскрытия).

Я не думаю, что кого-то слишком заботят версии целых групп фреймворков. Честно говоря, если бы я считал, что это поможет большинству клиентов, я бы проголосовал за простое изменение чисел - я просто не верю, что это поможет почти вообще. Это просто изменило бы наше сообщение на «да, вы сломались - это то, что говорится в версии, вы просто не понимали, с какими вещами вы соглашаетесь, принимая версию», что является неубедительным оправданием IMO.

Учитывая разницу во мнениях, мне интересно, что думают другие: пожалуйста, используйте голоса за / против этого сообщения:

• 👍 если вы согласны со мной, т.е. вы думаете, что отправка критического изменения в версии 5.0 не будет иметь никакого значения, и большинство людей все равно будут сломаны, сбиты с толку и затронуты.
• 👎 если вы согласны с предложением @robertmclaws , то есть считаете, что отправка

Для управления версиями критических изменений я думаю, что 5.0 - хорошая идея, но я не очень сильно в этом уверен.

Я все еще очень не понимаю, что вызывает эту проблему в первом
место. Вы, ребята, действительно говорите над моей головой.

Меня очень волнует соответствие номеров версий, но если это
пойти, чтобы эта проблема прекратилась, я с ней разберусь.

Разве я не читал несколько месяцев назад статью о том, как большинство
Библиотека System.Net.Http заката в пользу перестроенной?

15 декабря 2016 г. в 15:18 «Карел Зикмунд» [email protected] написал:

@robertmclaws https://github.com/robertmclaws Мы не думаем, что
изменение версии будет иметь значение. Большинство людей (приложение и библиотека
владельцы) обычно просто "обновляют до последней версии" в своих пакетах, они
неважно, насколько изменилась версия (младшая или основная). Итак, нарушение
воздействие будет точно таким же.
Еще хуже то, что эффект "ломки" обнаружится только тогда, когда
вы комбинируете несколько вещей. Вот почему эта проблема проскользнула в
первое место - у нас нет тестирования для этой комбинации (и я бы сказал
это нормально - невозможно проверить все комбинации, но мы можем обсудить это в
посмертное позже).

Я не думаю, что кого-то слишком заботят версии целых групп фреймворков
или. Честно говоря, если бы я считал, что это поможет большинству клиентов, я
проголосовал бы за изменение числа - я просто не верю, что
помогают почти все. Это просто изменило бы наше сообщение на "да, ты
сломан - так написано в версии, просто вы не понимали, что за
вещи, с которыми вы соглашаетесь, принимая версию ", что является неубедительным оправданием ИМО.

Учитывая разницу во мнениях, мне интересно, что думают другие:
пожалуйста, используйте голоса за / против этого сообщения:

• 👍 если вы согласны со мной, т. Е. Вы думаете, что отправка критических изменений
  поскольку 5.0 не будет иметь значения, и большинство людей все равно будет сломано,
  смущенный и пораженный.
• 👎 если вы согласны с @robertmclaws https://github.com/robertmclaws
  предложение, то есть вы думаете, что отправка критического изменения в версии 5.0 поможет
  люди заранее понимают, что им лучше держаться подальше от пакета,
  потому что это нарушит комбо с другой библиотекой и предотвратит
  ненужная боль разработчикам.

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267446604 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAavtBRE24SlHsZHCYm5OhPbOGs6MfRzks5rIa68gaJpZM4JsdDX
.

Я согласен. Сегодня я получил некоторые подробности из электронного письма, но все еще не уверен. Было бы неплохо увидеть хорошее описание внутренней проблемы, чтобы мы понимали предлагаемые решения.

@karelz Я ценю то, что вы здесь пытаетесь сделать, но участие в опросе о том, что означает «версия 5.0», - пустая трата времени. GitHub - это общение, а не инженерия. Я бы отправил версию 5.0 СЕГОДНЯ, которая исправляет это, и отправлю 6.0, когда вы поймете, как правильно настроить все свои маленькие аннотации и / или провести рефакторинг кода.

Заявления вроде «Большинство людей (владельцев приложений и библиотек) обычно просто обновляют до последней версии» бесполезны. Вот как Perl 6, Python 3, Rails 3 и 4 и Node.js 1,2,3,4,5 и 6 смогли расколоть вещи. Давайте не будем следовать этому примеру.

@dluxfordhpf @ciel К сожалению, это сложно объяснить. Все это исходит из «устаревшей» системы защиты доступа с кодом, которую больше не рекомендуется использовать.

Вот краткое изложение его предназначения:
https://msdn.microsoft.com/en-us/library/ee191569 (v = vs.110) .aspx
https://msdn.microsoft.com/en-us/library/dd233102 (v = vs.110) .aspx

Фактическая проблема связана с тем, что сказал

В контексте документов выше посмотрите этот раздел о правилах наследования.

В нем описаны правила, необходимые для наследования типов на разных уровнях безопасности.

Благодаря! Я знаком с CAS; техника замечательная.

Учитывая все изменения номеров версий между .NET Core, .NET Standard и др. al. в прошлом году (и поставляя новый код версии 4.3 на NuGet, который работает на 4.6.2, я понимаю, что Microsoft может не думать, что номера версий имеют значение. Но как человек, который единолично управляет очень сложной архитектурой приложения и поставляет более 20 OSS NuGet пакеты, я категорически не согласен.

Нажатие «Обновить все» без проверки совместимости - это самый простой способ в .NET испортить ваше приложение и не узнать об этом до времени выполнения. Приверженность SemVer - единственный способ сохранить хоть какое-то чувство здравомыслия. Увеличение основной версии означает, что что-то сломается. Когда вы сигнализируете об этом изменении, вы получаете свободу делать все, что хотите, чтобы исправить.

Предлагаемое исправление звучит для меня хорошо, но я просто хотел бы прокомментировать тестовую матрицу - использование HttpClient на настольной .NET станет важным событием в обозримом будущем. Эта комбинация действительно должна быть проверена, хотя верно, что не все возможности могут / должны быть проверены.

Да, тест для меня тоже звучит как отговорка. Добавьте 100 лучших пакетов в свой проект модульного тестирования и убедитесь, что ваш дерьмо все еще работает. Похоже на то, что Microsoft делала базовую разработку, прежде чем осознала, что может уволить тестировщиков и позволить «сообществу» разобраться с этим. Это просто ужасная и досадная трата времени.

Потому что «старый» QA, который принес нам Windows ME и Vista, был лучше.

Кроме того, я уверен, что оскорбление их сделает работу быстрее.

16 декабря 2016 г., 7:46, «chadwackerman» [email protected] написал:

Да, тест для меня тоже звучит как отговорка. Добавить 100 лучших
пакеты в свой проект модульного тестирования и убедитесь, что ваше дерьмо все еще работает.
Похоже на то, что Microsoft делала раньше
понимая, что они могут уволить тестировщиков и позволить "сообществу" разобраться в этом
вместо этого. Это просто ужасная и досадная трата времени.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267597137 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAavtAUL3pmMiSRnFBe7DEa0y5AaZoVXks5rIpZIgaJpZM4JsdDX
.

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

16 декабря 2016 г. в 8:26 утра "chadwackerman" [email protected] написал:

Выкрикивая чушь, хотите верьте, хотите нет, работа выполняется быстрее.
В противном случае у вас есть менеджеры-миллионеры, которые не написали ни строчки
код за 10 лет, говоря: «Ух ты, эта штука на Github, конечно, классная. Давайте взломаем
Проголосуйте за смайлики и проведите голосование, чтобы мне не приходилось принимать решение ".
Как будто это что-то решит после человеко-месяцев работы и шести
часы внутренних встреч по сортировке. Это ложная социальная сигнализация и
откровенно говоря, те инженеры BS, которые раньше называли, что принесло нам качество
как ракета Сатурн V. И .NET, который был лучшим языковым пакетом
и стандартная библиотека всего в этом пространстве задолго до всего этого онлайн
начался идиотизм.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267604666 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAavtEigDK5EqlA4LQVlxB_lfamMgHanks5rIp9-gaJpZM4JsdDX
.

Или, может быть, вы нашли парня, который научился разблокировать всю свою команду, заставив Microsoft наконец принять меры по проблеме, которая игнорировалась в течение нескольких месяцев.

У Microsoft есть полностью дублирующие списки ошибок и приоритеты внутри компании. Github - это куча социальной чепухи. В любом случае они не будут принимать запросы на перенос по этой проблеме, поэтому они превращаются в поток поддержки клиентов. Разработчики проделали здесь плохую работу, и для них это нормально слышать это.

Есть большая разница в том, что разработчики слышат это и
невыносимый засранец. Если оскорбительные замечания - это единственный способ выразить
точка, тогда, возможно, тебе стоит продолжать ругать людей, которых ты, по крайней мере,
платит, чтобы мириться с вами.

16 декабря 2016 г. в 8:34 "chadwackerman" [email protected] написал:

Или, может быть, вы нашли парня, который научился разблокировать всю свою команду с помощью
заставить Microsoft наконец-то решить проблему, которая месяцами игнорировалась.

У Microsoft есть полностью дублирующие списки ошибок и приоритеты внутри компании.
Github - это куча социальной чепухи. Они бы не приняли пул-реквест за
эта проблема в любом случае, так что это превращается в поток поддержки клиентов. Разработчики
здесь плохо поработали, и им это нормально слышать.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267606461 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAavtHTdxym7pvR9KRomyIT14FVaILLFks5rIqF8gaJpZM4JsdDX
.

Я отвечу только потому, что Microsoft использует «sort by GitHub number_of_comments», чтобы помочь в том, что @karelz так вежливо слил, как «выяснить финансирование». Вы также можете использовать шкалу эмодзи GitHub, чтобы подтвердить свои социальные ценности.

Чувак вошел и сказал, что СемВер не имеет значения. Наш долг как инженеров - показать, насколько это абсурдно. Это классический случай, когда нам нужен более старший менеджер, у которого есть реальный опыт, или более молодой парень, который действительно знает, как вещи влияют на реальный мир. Реальная проблема здесь - менеджеры среднего звена, играющие роль мэра на GitHub. Теперь не стесняйтесь щелкать пальцем вниз, чтобы мы все могли продолжить наш день, спасибо.

Да, эта ошибка - отстой, и я удивлен, увидев выпущенный основной путь sev1. Но ИМХО настоящая боль от этого связана с дизайном NuGet: любой пакет NuGet, который использует проект, должен быть вручную указан всеми потребителями этого проекта. Это ненужное дублирование и плохой дизайн, это настраивает вас на провал. Мастер синхронизации бесполезен при плохой базовой конструкции. NUGET - вот почему эта ошибка так болезненна. В противном случае мы бы возмутились, поместили неприятный обходной путь в Util и смогли бы о нем забыть. Но теперь мы должны проявлять осторожность во всех 18 или около того потребляющих проектах, которые растут каждый месяц. Вот почему эта ошибка так болезненна - из-за NuGet исправление невозможно изолировать для одного проекта, вам нужно все трогать и продолжать делать это.

Кроме того, я разделяю мнение о важности Desktop / Windows .NET. Я рад слышать о том, что Microsoft .NET приходит в Linux, но деньги идут на Windows, это то место, где мы должны получить лучший опыт, и я хочу, чтобы он работал лучше всего.

Моя команда постоянно недовольна: «Почему мы должны загружать все эти пакеты?» Мы создаем консоль или проект ASP.NET и все необходимое находится в коробке. Вы создаете что-то более современное и 5 миллиардов скачиваний.

Хорошо, я ухожу немного далеко. Спасибо за ваше время и внимание, дайте мне знать, если мы можем помочь вам протестировать / оценить / проверить документы на наличие опечаток / все, что вам нужно, мы готовы помочь.

Причина, по которой эта проблема (и dotnet / runtime # 17786) вызвала у нас столько боли, заключается в том, что мы переместили наши облачные службы из веб-ролей Azure в службы Service Fabric и должны были перейти на netcore / netstandard, но все еще работаем в полной структуре. Программы.

Сначала я применил обходной путь перенаправления привязки, который, казалось, работал какое-то время, но наши разработчики постоянно что-то ломали, случайно возвращая app.config, обновляя пакет nuget и борясь с AutoGenerateBindingRedirects (отключение которого было собственным кошмаром).

Наконец, я решил эту проблему, заставив везде использовать HttpClientHandler. Это включало изменение нашего собственного кода, возникновение проблем в сторонних библиотеках и даже использование хаков, таких как отражение и дублирование стороннего кода, для решения проблемы.

Итак, каким бы ни было решение, если новый пакет не поддерживает новый HttpClient / HttpClientHandler, мы его не примем. Это не большая проблема, потому что сейчас все работает. Однако «настоящее исправление» должно произойти вскоре после этого, поскольку я не хочу, чтобы меня блокировали при обновлении еще большего количества сторонних пакетов, которые могут перемещать свой код на netstandard и создавать эту проблему.

@dluxfordhpf ... Было бы неплохо увидеть хорошее описание внутренней проблемы, чтобы мы понимали предлагаемые решения ...

Я попытался описать проблему здесь: https://github.com/dotnet/corefx/issues/11100#issuecomment -267394198.
В двух словах:

• Пакет Http NuGet 4.1 / 4.3 «переопределяет» Http 4.0 в .NET Framework, но не имеет атрибутов безопасности. Более того, он использует другой компонент ОС под капотом (например, «большое изменение» + потенциально ломающие уголки (хотя это не имеет прямого отношения к этой проблеме, это признак того, что у него есть проблемы)).
• WebRequestHandler является только частью .NET Framework, но зависит от Http 4.0 и требует атрибутов безопасности в Http.
• После того, как вы возьмете зависимость от Http 4.1 / 4.3 от NuGet и перенаправите на нее версию .NET Framework 4.0 для входящих сообщений, вы не сможете использовать WebRequestHandler.
• Что еще хуже, Http имеет несколько новых API, которые являются частью .NET Standard 1.6, и некоторые компоненты зависят от них. Так что просто вернуться к старой версии мы не можем.
• И, конечно, детали еще больше усложняют.
• Заявление об очевидном: «правильного решения» не существует. Это вопрос выбора того, который в целом оказывает меньшее влияние.

@chadwackerman ... участие в опросе о том, что означает «версия 5.0», - пустая трата времени. GitHub - это общение, а не инженерия.

Это не общение. Если вы посмотрите на голоса, то увидите, что единого мнения по этому поводу нет. Так что даже если вы не доверяете мнению команды CoreFX (с более чем 10-летним опытом работы с клиентами .NET), в котором говорится, что « люди не обращают внимания на основную версию, как мы того желаем », я надеюсь, что это поможет увидеть, что даже некоторые MVP ( @onovotny) разделяю это мнение. В то время как другие MVP не согласны (@robertmclaws).

@chadwackerman ... Я бы отправлю 6.0 ..

Это вариант [2], который я изложил выше (с разными номерами версий). Это то, что мы исследуем параллельно. Учитывая влияние решения, неясно, « да, это, очевидно, правильное решение, давайте действовать ».

@robertmclaws ... Microsoft может не думать, что номера версий имеют значение ... Когда вы сигнализируете об этом изменении, вы получаете свободу делать все, что хотите, чтобы исправить это ...

Я не пытался сказать, что мы не верим в правильное управление версиями. Мы просто считаем, что значительную часть разработчиков это не волнует, и мы хотим, чтобы все всегда было полностью совместимо, т.е. мы не можем делать все, что хотим, даже в мажорной версии. Это основано на многолетнем опыте нашей команды в обслуживании .NET и доставке пакетов NuGet.

@gulbanana ... Эта комбинация действительно должна быть проверена, хотя это правда, что не все возможности могут / должны быть проверены ...

Согласны, теперь, когда мы знаем, что это важная комбинация, мы должны добавить ее покрытие. И мы должны потрогать эту область еще немного, чтобы увидеть, не упускают ли мы другие подобные комбинации вокруг пакета Http NuGett.

@chadwackerman ... Добавьте 100 лучших пакетов в свой проект модульного тестирования ...

Как ни странно, это похоже на то, что я предлагал год назад, когда мы отправили плохой метапакет для UWP из-за отсутствия правильного тестового покрытия. Это не так-то просто. Чтобы отловить интересные ошибки (например, эту), вам также нужно потренировать код. Часто вам приходится выполнять код из обеих комбинаций в одном тесте (не в этом конкретном случае). В целом чертовски сложно в тесте ниже.
Если у вас есть предложения и идеи, которые мы могли упустить, дайте нам знать - давайте просто напишем новый выпуск по этой теме.

@chadwackerman ... и пусть вместо этого "сообщество" разбирается с этим ...

Мы (я могу говорить от имени команд CoreFX и CLR) НЕ передаем на аутсорсинг тестирование продуктов сообществу через GitHub. Мы держим высокую планку качества поставляемой продукции.

(случайная горячая клавиша отправила ответ до того, как я его закончил ... продолжение следует ...)

@chadwackerman ... У Microsoft полностью дублируются списки ошибок и приоритеты внутри компании ...

Неправда, по крайней мере, для команд CoreFX и CoreCLR - GitHub - это основная база данных ошибок для всех .NET Core. Другие продукты с открытым исходным кодом («полная» .NET Framework и .NET Native) используют в основном внутренние базы данных ошибок.

@chadwackerman ... Они все равно не будут принимать

Мы не принимаем пул-реквест, который не может решить / объяснить все вышеперечисленные проблемы (включая те, с которыми лицо, отправившее его, лично не согласен). Существуют ли проекты с открытым исходным кодом, которые нужно быстро взломать, не обдумав всех его последствий? Может быть, если 20% + клиентов находятся в зале ... это не так (пока).

@chadwackerman ... Microsoft использует «сортировку по GitHub number_of_comments», чтобы помочь в том, что @karelz так вежливо слил, как «выяснить финансирование». ...

Во-первых, number_of_comments - это не показатель, на который мы обращаем внимание (если только кто-то «вручную» не заметит, что он выходит из-под контроля). И никакого отношения к «финансированию» это точно не имеет.
Мы обращаем внимание на все, что влияет на клиентов - либо количество голосов, либо выраженное недовольство клиентов (на GitHub, Twitter, в комментариях к блогам и т. Д.).
Эта ошибка попала на мой радар как «значительное недовольство клиентов» (другой сотрудник MS в этой ветке поднял ее как таковой внутри компании), поэтому я вмешался.
В настоящий момент мы финансируем его изо всех сил. Единственным более высоким приоритетом будет проблема безопасности, или более 20% наших клиентов остаются без решения проблемы.
Кстати: оскорбления не помогут ускорить процесс и не повлияют на принятие решения.

@dluxfordhpf ... пожалуйста, дайте мне знать, можем ли мы помочь вам протестировать / оценить / проверить документы на наличие опечаток / все, что вам нужно, мы готовы помочь ...

Спасибо, мы ценим ваше предложение. Мы определенно будем приветствовать помощь, когда у нас будут готовые биты (и проверенные на имеющихся репродукциях), чтобы проверить больше сквозных сценариев. Мы хотим избежать ситуации, когда мы исправляем только одни сквозные сценарии, оставляя другие сломанными тем же или другим способом.

@jahmai ... но наши разработчики постоянно что-то

Благодаря! Это хороший пример прояснения влияния проблемы на повседневную работу разработчиков, которую мы должны услышать и понять. Это помогает нам понять, что комбинация с инструментами VS превращает эту работу в настоящий кошмар. Мы учтем это при доработке плана выпуска и сроков (что я начну, как только мы определимся с решением).

@jahmai ... если новый пакет не поддерживает новый HttpClient / HttpClientHandler, мы не будем его использовать ...

Опять же, хорошие отзывы. Мы все еще пытаемся избавиться от всей истории сквозных исправлений и выпуска, прежде чем полностью купимся на одно решение. Выпуск взлома, не понимая, как это повлияет на другие сценарии (например, ваш), будет для нас отчаянным шагом - мы будем рассматривать его только в том случае, если мы не знаем, как его исправить, или если правильное исправление будет чрезвычайно дорогостоящим. Мы еще не там.

Пожалуйста, давайте продолжим обсуждение технических вопросов.

Быстрое обновление:
Решение [3] « Посыпать атрибуты безопасности в System.Net.Http », как описано выше, кажется дорогостоящим (6w +), поэтому мы повторно изменили детали его внутренней реализации: мы рассматриваем возможность использования исходной реализации Http из версии пакета 4.0. + реализовать 8 новых API поверх него, насколько это возможно (некоторые могут технически не работать с обходными путями). Поддержка http2 и другие полезности "нового стека WinHttp" не будут доступны по умолчанию, кому бы они ни понадобились, нужно вызвать специальный конструктор (технически критичное изменение, но, надеюсь, не многие люди зависят от новых внутренних компонентов 4.1 / 4.3) .
Стоимость пока кажется значительно ниже, но мы все еще ищем и оцениваем 2 проигрыша (API), прежде чем остановимся на окончательном плане. Придется принять некоторые «интересные» решения о совместимости как минимум для двух API, но они не должны замедлять время выпуска исправления.

Кстати: Решение [2] « Отменить решение OOB » оказывает большее влияние, чем мы первоначально предполагали (например, оно нарушит .NET Standard 1.6, создавая более длительный беспорядок и объяснения). В настоящий момент мы оставляем это в качестве крайней меры, если вышеперечисленное окажется слишком дорогостоящим или неоправданным.

если вы в настоящее время рассматриваете крайние случаи, связанные с этой проблемой, стоит проверить это:
https://github.com/gulbanana/repro-netstandard-httpclient

это решение демонстрирует, что в настоящее время в vs2017rc использование netfx и netstandard приводит к конфликту версий system.net.http. Я не уверен, как это связано с OOB.

Я ценю (и искренне восхищаюсь) откровенностью @karelz здесь, но я собираюсь в последний раз

если вы не доверяете команде CoreFX (с более чем 10-летним опытом работы с клиентами .NET) мнение, которое гласит: «Люди не обращают внимания на основную версию» ... основанное на многолетнем опыте нашей команды с обслуживанием .NET и доставкой NuGet пакеты ...

Я не уверен, что это за логическая ошибка, но вы не можете претендовать на глубокое понимание опытной командой нюансов управления версиями посреди такой масштабной проблемы управления версиями, как эта.

Надеюсь, мы, по крайней мере, сможем согласиться с тем, что НЕ увеличивать номер основной версии и не вносить критические изменения - это худший из миров. Но вот мы здесь. Говоря о «бюджете» и «6+ недель времени на разработку» ... вкратце о некоторых атрибутах. Для устаревшей системы доверия, которая никогда не работала и которую я не использую. Из-за неучтенных проблем в компиляторе.

Прошлым летом Amazon Web Services предоставила полную поддержку .NET Core для всех своих сервисов. Их недавнее обновление снижает планку netstandard с 1,5 до 1,3. Между тем команда Azure не может даже заставить работать большие двоичные объекты.

Вы, ребята, отправили биты, которые глобально нарушают веб-запросы https, тихо во время сборки и громко во время выполнения, и у вас все еще нет плана решения этой проблемы четыре месяца спустя. Я оставлю это сейчас, потому что, очевидно, вы работаете над этим - но если более серьезные проблемы здесь не мешают вам спать по ночам ...

Большое спасибо за вашу откровенность и ваши объяснения.

@chadwackerman ... вы не можете претендовать на глубокое понимание опытной командой нюансов управления версиями посреди такой масштабной проблемы управления версиями, как эта. ... Надеюсь, мы сможем по крайней мере согласиться с тем, что НЕ увеличивать номер основной версии и не вносить критические изменения - это худший из миров. Но вот мы здесь. ...

Вы делаете 2 больших предположения:

1. Предположение: критическое изменение известно (также известное как нарушение) перед отправкой.
   
   
   
   • Это не относится к данной проблеме - как это обычно бывает с классом «непреднамеренных критических изменений». Да, иногда что-то проскальзывает :(. Важными показателями являются ИМО: быстрая реакция (я согласен, что до сих пор мы не делали этого прямо по этому вопросу) и уменьшение / низкая частота таких ошибок.
   
   
2. Предположение: эксперты по версиям способны анализировать каждое изменение (а это не так) и что люди в целом никогда не ошибаются (научная фантастика).
   
   
   
   • В этом конкретном случае план API System.Net.Http (новые 8 API для настольных ПК) был рассмотрен на высоком уровне перед отправкой также экспертами по управлению версиями. Они предоставили предложения и рекомендации по вариантам. К сожалению, уровень взлома не был признан заранее никем (ни региональными экспертами, ни экспертами по версиям), поэтому выбранное решение привело к этим проблемам.
   
   

Я также хочу отметить, что, игнорируя наш опыт в управлении версиями, вы, по сути, говорите: « Если вы (команда .NET) когда-нибудь совершите большую ошибку (эту ошибку), вам не разрешено называть себя экспертом даже по прошлой истории и клиентам шаблоны (связанная область) ".
Это большой молоток ИМО и нереально. Люди / команды совершают случайные ошибки (например, эту). Это не делает их непригодными для того, чтобы быть экспертами в близлежащих областях (или даже в определенной области). Главное, смогут ли они научиться на своих ошибках и добиться большего успеха в будущем.

@chadwackerman ...

Стоимость не из-за «атрибутов пощечины», это простая часть. Дорогостоящая часть взята из открытого вопроса по варианту [3]:

https://github.com/dotnet/corefx/issues/11100#issuecomment -267394198: Открытый вопрос: можем ли мы заставить внутренние зависимости WebRequestHandler работать с новой системой System.Net.Http на основе WinHttp?

Оказывается, работы довольно много, внутренние зависимости слишком неприятны :(

Я очень ценю обсуждение этого вопроса. Шутки в сторону. Это круто. Спасибо, что были открыты по этому поводу.

В конце концов, вот проблема dotnet / corefx №1: вы, ребята, переписали большую часть стека. Часть, которая занимает центральное место почти во всем. И у вас нет даже отдаленно адекватного тестового покрытия. Не стоило нуждаться в специалистах. У него должен был быть четко задокументированный тестовый пример, который был написан во время написания WebRequestHandler (или было принято решение не переносить его на Core), и он должен был сломаться, когда вы, ребята, начали с ним копаться.

После более чем 5 лет выпуска материалов, связанных с .NET 4.0, действительно нет оправдания тому, что НИКОГДА не было покрытия интеграционного тестирования, которое могло бы это обнаружить. Если вы находите себе оправдание, значит, вы не требуете от своей команды совершенства.

Если бы было:

• надлежащее тестовое покрытие
• надлежащий процесс обеспечения качества
• надлежащая бета-версия
• и правильный способ отправки проблем конкретным командам, ответственным за определенные пакеты

... этого бы не случилось.

Если команда:

• не были так одержимы кипячением океана, переписывая КАЖДЫЙ ОДИН АСПЕКТ .NET одновременно
• прислушался к предупреждениям тех из нас, кто высказывался по этому поводу с самого начала проекта ".NET 5 / MVC 6"

... этого бы не случилось.

Это комбинация сбоев, которые сломали .NET в целом, в таком масштабе, о котором я никогда не помню, чтобы случалось раньше. Но вы также нарушили большую часть экосистемы, и исправить это становится все труднее.

Это очень реальная и значительная цена. Нам пришлось отключить наш CI-сервер несколько недель назад и развернуть его вручную, каждый раз проверяя файл web.config вручную. Развертываем не реже одного раза в день. Сотни долларов в неделю дополнительных человеко-часов, не говоря уже о задержках из-за необходимости тратить это время на что-то другое.

Опять же, это даже не принимая во внимание бесчисленные часы работы с существующими недостатками в архитектуре HttpClient: это неправильное удаление экземпляров, сохранение открытых TCP-соединений и слишком долгое кеширование записей DNS.

Итак, вы собираетесь поймать немного на этом. И это заслуженно.

И, исходя из того, насколько «дорого» исправление, я надеюсь, что вы поручаете команду из нескольких ваших лучших людей исправить это правильно, а не перекладываете это на плечи одного человека.

... Избиения будут продолжаться до тех пор, пока моральный дух не улучшится.

Пусть они исправят ошибку, в которой они признались, и не будут связаны тактичностью.

Просто чтобы нам было понятно, я не пытаюсь победить мертвую лошадь своим последним постом. Но в последнее время я видел слишком много оправданий со стороны Microsoft. «Именование - это сложно». «Управление версиями - это сложно». «Люди делают ошибки». Это менталитет слабости, а не команды, стремящейся к совершенству. Я действительно восхищаюсь @karelz за то, что он пришел сюда и обсудил это. Но любой сотрудник MSFT должен перестать оправдывать то, что произошло, и позволить людям высказаться, не чувствуя необходимости тратить время на исправление записи. Это не какое-то исключительное исключение, когда вы используете DateTime или что-то в этом роде. Это колоссальное выпадение из-за того, что более одного человека не требуют совершенства в своей работе, и к нему следует относиться как к такому. Единственный действительный ответ: «Мы облажались. Мы сломали .NET. Мы не собираемся отдыхать, пока он не будет исправлен». Потому что это было бы реакцией 5 лет назад, когда Гу вел шоу.

Я сочувствую @karelz, который только недавно занял свою должность после долгого времени работы над .NET. И уж точно не должен защищать свою команду. Я не виню здесь рабочих; это, очевидно, проблема менеджмента.

Но, возможно, не должно вызывать удивления то, что круговая логика и вид двойного разговора, который широко распространен на определенных уровнях управления Microsoft, не работают хорошо перед реальными клиентами, которые действительно используют эти вещи.

В .NET Core Microsoft SQL Server потерял возможность записывать беззнаковые значения. Снова забытая проблема, которая находится на вершине сайтов UserVoice еще в 2014 году. Предприятия не могут позволить себе изменить схему своей базы данных (особенно такую ​​тонкую, как неподписанная), потому что пара менеджеров программ не может попасть на одну и ту же страницу после трех лет. Между тем, Redis и SQLite (что бы это ни было) работают нормально, а Скотт Хансельман раскачивает демонстрации выставок, как будто это действительно работает. Здесь определенно увеличивается разрыв между внутренней и внешней реальностью, и проблемы необходимо (вежливо) решить.

Назвать сложно. Управление версиями - это сложно. У Microsoft есть уникальная перспектива, когда они имеют дело с клиентами из самых разных отраслей, от самых передовых до умирающих. Концепции подхода к разработке, которые кажутся «очевидными» в играх, чужды CRM-системам. То, как вы подходите к проблемам, что важно, а что не важно, различается. А затем вы добавляете передовые технологии, различные подходы к проблемам: DAO vs ADO.NET vs LINQ vs EF, чтобы использовать простое простое сравнение. Наконец, конкуренция в области Интернет-серверов, совершенно новые модели оборудования с планшетами под ключ и вирус Balmer. Совершенно новые способы мышления и моделирования проблем с различными ограничениями и преимуществами.

Одно время я работал в… крупной известной компании. Одна группа продуктов выпустила продукт с обновленным общим компонентом, который по-разному интерпретировал его стек вызовов в зависимости от того, как он был инициализирован. Они никогда не тестировали это с нашим продуктом, и каждый раз это заставляло наш продукт расти. Очевидно, но они все равно отправили его. Мы назвали это происшествием «дружественный огонь».

Однажды я пропустил ошибку, из-за которой при установке на диск D при удалении при определенных условиях продукт мог… удалить все файлы на жестком диске. Нам пришлось записать прессованные компакт-диски за 40 тысяч долларов.

Люди несовершенны, и мы делаем ошибки. Однако обвинять - бесполезное понятие. Это заставляет нас чувствовать себя сильными благодаря разрушительным понятиям, таким как стыд и унижение. Смирение и прощение сильнее. Вот как мы добиваемся большего, изучаем лучшие способы, а иногда просто почему что-то важно в первую очередь.

Да, проблема меня тоже злит, но она решается. И знаете что - подобные проблемы с открытым исходным кодом томятся десятилетиями, прежде чем все равно стоит даже попытаться. Просто попробуйте использовать Kerberos в системе Linux или загляните в GSSAPI. InitializeSecurityContext / AcceptSecurityContext НАСТОЛЬКО проще. Деньги имеют значение.

Одно время я работал в… крупной известной компании. Одна группа продуктов выпустила продукт с обновленным общим компонентом, который по-разному интерпретировал его стек вызовов в зависимости от того, как он был инициализирован. Они никогда не тестировали это с нашим продуктом, и каждый раз это заставляло наш продукт расти. Очевидно, но они все равно отправили его. Мы назвали это происшествием «дружественный огонь».

Это были два разных продукта. .NET - это единый продукт. И я не пытаюсь винить кого-то одного. Я виню процесс. Похоже, что из-за того, что Microsoft перешла на OSS, они выбросили процессы, которые помогли им выпустить самую стабильную среду разработки в истории. Я чувствую, что это было бы замечено, если бы оно было отправлено в .NET 4.6.3 вместо NuGet.

Неуклюжий переход на OSS определенно не помогает. Я не виню OSS, но Microsoft определенно гордится всеми очевидными ошибками.

Для описания программного обеспечения я использую такие слова, как «качество», но теперь они используют такие слова, как «взаимодействие». Запуск инструментального компилятора, который звонит домой дополнительно двадцать раз в день, потому что мне приходится вручную редактировать файлы .config, не является «дополнительным занятием». Но в наши дни это миф всего Интернета.

Рассмотрим команду BashOnWindows, которая решила попросить группу людей с нулевым опытом работы с Linux написать прокладку пользовательского режима Linux в прямом эфире на GitHub. Это простая, но утомительная работа по проектированию, и нет абсолютно никаких причин для привлечения отзывов сообщества для определения приоритетов функций. Но они ушли.

Спустя шесть месяцев «сообществу» пришлось сказать им, что оно не может обрабатывать файлы, которые заканчиваются за период. Это не программная инженерия; это какое-то странное маркетинговое упражнение. Менеджеры, которые неявно включены в схему, заслуживают обратной связи. И кое-что из этого может быть неприятно слышать.

Отредактируйте, чтобы добавить: аналогичная сделка с фиаско Bash. Доставка сломанных битов вживую, странные связи с другими компонентами (можно было установить только как часть Windows Update) и, конечно, Скотт Хансельман каким-то образом делал живые демонстрации, несмотря на то, что он не мог запускать tar, не говоря уже о компиляторе.

Некоторая риторика здесь попахивает «старыми добрыми днями» Microsoft, что иронично, потому что все изменения, которые мы наблюдаем сейчас, являются прямым ответом на потребительский спрос на развитие Microsoft.

Нам надоели закрытые исходные коды и драконовские правила обратной инженерии (декомпиляции), поэтому мы получили ссылки на источники, а теперь и с открытым исходным кодом.

Нам надоели ошибки .net Framework, которые затрагивали каждое приложение, установленное на машине, и требовалось много времени для исправления и требовалось, чтобы корпоративные дистрибутивы и ИТ-отделы проверяли каждое обновление версии .NET Framework до того, как это могло произойти, поэтому теперь мы движемся отправка пакетов nuget с нашими приложениями, чтобы мы могли отправить исправление, как только оно будет доступно.

Мы устали от того, что Microsoft Connect закрывает все остальные ошибки как «работающие так, как задумано» или занимает 6 месяцев, чтобы даже составить график выпуска, поэтому теперь у нас есть проекты Github, которые гораздо более тщательно управляются командой, которая на самом деле пишет код, и все сообщество может легко дать свои 2 цента за каждый рабочий элемент, поднятый сообществом.

Нам надоело, что Microsoft брала все хорошие идеи сообщества и создавала проприетарный клон, который не работал с инструментами сторонних разработчиков, поэтому теперь мы можем использовать NPM, Gulp, NodeJS и т. Д.

Нам надоело то, что C # жизнеспособен только для Windows, а такие проекты, как Mono, изо всех сил пытались поддерживать нормальный уровень, при этом нам приходилось обходить ошибки или отсутствие функциональности с #ifdef повсюду, поэтому теперь у нас есть Xamarin, продвигающий разработку Mono со справочными источниками и позволяющий нам кодировать последнюю версию языка C # и использовать одну и ту же базу кода для .net, UWP, iOS, Android и netcore.

Все это происходит сразу, потому что это произошло. Мы не собираемся ждать, пока Microsoft будет играть в догонялки, пока она поставляет идеальные стабильные функциональные возможности, которые решают только половину наших проблем в любой момент времени.

Моя проблема не в том, что все эти изменения происходят сразу. И не о том, чтобы подобные проблемы появлялись. Настоящая проблема для меня в том, что _ потребовались месяцы, чтобы эта проблема была признана серьезной, _ и еще несколько месяцев уходит _ на

Три недели и никаких обновлений. Всех с Новым годом.

Отредактируйте, чтобы добавить эту цитату из @karelz, поскольку преуменьшение, похоже, вызывает здесь немного другую группу особых снежинок:

Я буду публиковать обновления (надеюсь, с более подробной технической информацией), когда они будут у нас, по крайней мере, еженедельно.

@chadwackerman серьезно, вы понимаете, что ваше плохое отношение не поможет

Какой тон? Он сделал заявление, которое имеет преимущество быть точным, а затем пожелал всем счастливого Нового года. Если вы восприняли это отрицательно, это ваша проблема.

Что касается первого утверждения: это серьезная проблема, которая не проявляется до времени выполнения. Пять лет назад у ScottGu или Роба Ховарда была бы команда, работающая круглосуточно, пока исправление не было отправлено. Теперь это просто «вы знаете, мы до этого дойдем».

Вы знаете, что сделает людей счастливыми? Решить проблему. В противном случае есть несколько рассерженных клиентов, и некоторые из них находятся в этой ветке. У них есть полное право злиться. Итак, @pollax, найди что-нибудь еще, чтобы развеять свое негодование. Вы не добавили ничего значимого в эту ветку, и никто не помазал вас в GitHub Thought Police. Вы также не потратили на эту проблему более $ 5 тысяч денег своей компании.

Ладно, может быть, я слишком много в нем прочитал, и из-за тона, который он использовал в предыдущих комментариях, я прочитал последний с немного иронией. Прости за это.
Что касается вопроса; Я слышу тебя. Меня это беспокоит (иначе я бы не стал так внимательно следить за этой проблемой), поэтому, пожалуйста, не делайте предположений о том, что я потратил / не потратил на это с точки зрения денег / ресурсов. Но как разработчик я знаю, что худшее - это когда кто-то смотрит на вас, пытаясь исправить серьезную проблему.

Я согласен с вашим пониманием сарказма и согласен, это непродуктивно. Я также согласен с тем, что «когда это будет исправлено». К сожалению, проблема CAT1 на основном пути просто не привлекала внимания, пока многие люди не стали ее обсуждать. Я надеюсь, что есть некоторые улучшения внутреннего процесса, чтобы решить эту проблему; для всех нас было бы отстойно, если бы мы могли исправить ситуацию только с помощью проклятых слов.

Я также получаю отчет об этом на полной платформе с нашим пакетом Nuget Exceptionless. Какие-нибудь серьезные исправления или обходные пути?

Я также получаю этот собственный хостинг ASP.NET Core из службы Windows, работающей на полной платформе 4.6.2. зависимость NETStandard.Library 1.6.1 заставляет меня использовать System.Net.Http 4.3.0.

зависимость NETStandard.Library 1.6.1 заставляет меня использовать System.Net.Http 4.3.0.

и это моя самая большая проблема во всей этой ситуации

все больше и больше пакетов зависят от метапакета, вынуждая меня обновлять каждую имеющуюся у меня зависимость (или вести тяжелую битву за понижение / игнорирование определенных)

это противоречит предыдущему обещанию «смешивать и согласовывать» системные зависимости.

Мне пришлось понизить версию моей системы до 4.5.2 с 4.6.1 (и потерять значительное время), потому что каждый второй пакет приносил .net 1.6 и его глючный System.Net.Http

Если бы это были только сторонние пакеты, ну, пусть так, я могу обойти их, приставать к сопровождающим, чтобы они использовали более гранулярные зависимости, но большинство моих зависимостей были от MS, и я ожидаю, что MS будет использовать гранулярные зависимости, а не просто вставьте .net 1.6 в файл nuget

Я планировал отправить обновление за последние несколько дней, так что вот оно:

Работе @CIPop помешала проблема безопасности. Его работу подхватил @davidsh. @davidsh планирует представить PR в начале этой недели (то есть в любой день).

Вот подробности о нашем плане выполнения и статусе:

План высокого уровня:
A. Замените WinHttpHandler на HttpClientHandler в сборке net46 CoreFX
Б. Реализовать 8 новых API-интерфейсов на HttpClientHandler, которые мы представили в пакете OOB 4.1.0.0.

План выполнения:

РЕДАКТИРОВАТЬ 2017/1/12 - план выполнения был перемещен в самый верхний пост https://github.com/dotnet/corefx/issues/11100#issue -173058293

@niemyjski Есть надежные исправления или обходные пути?

Существует обходной путь для понижения версии проблемного пакета до 4.0.0.0 (см. Https://github.com/dotnet/corefx/issues/11100#issuecomment-246469893), к сожалению, согласно комментариям выше, любое изменение зависимостей NuGet вернет его обратно. - что является ключевой причиной, почему этот вопрос так болезненен.

Я надеюсь, что есть некоторые улучшения внутреннего процесса, чтобы решить эту проблему; для всех нас было бы отстойно, если бы мы могли исправить ситуацию только с помощью проклятых слов.

У меня есть несколько идей (и вопросов) об улучшении процесса здесь, чтобы не допустить, чтобы важные важные проблемы в будущем так долго оставались незамеченными. Однако я намеренно откладываю это обсуждение ПОСЛЕ того, как мы отправим исправление.

Woot !!!

Молодцы ребята @karelz

Спасибо за обновления. PlatformNotSupported было бы лучше, чем ничего, поскольку это новые API, на которые устаревшее программное обеспечение не полагается.

Похоже, что после исправления, унификация через перенаправления привязки все равно потребуется, но перенаправление на более новую, а не на старую сборку, которую nuget может правильно сгенерировать?

Теперь, когда PR dotnet / corefx # 15036 отмечен, эта проблема должна исчезнуть с net46. System.Net.Http.dll теперь использует встроенный HTTP-стек из .NET Framework. Это означает, что он имеет 100% совместимость с WebRequestHandler.

Пожалуйста, попробуйте последние пакеты в ленте разработчиков MyGet. Вы захотите использовать последние созданные пакеты System.Net.Http.dll, которые на сегодняшний день:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

версия 4.4.0-beta-24913-02.

Вы можете использовать пакеты каналов разработки, изменив исходные каналы пакетов NuGet с помощью инструментов командной строки или Visual Studio.

Инструкции:

Командная строка:
Добавьте следующее в nuget.config в разделеэлемент:

<add key="myget.org dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />

Visual Studio:
В VS Инструменты-> Параметры-> Диспетчер пакетов Nuget-> Источники пакетов-> Добавить в разделе Источник используйте этот URL-адрес https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

В любом случае убедитесь, что вы указали канал MyGet dev в качестве первого канала в списке.

Подводя итог исправлению в dotnet / corefx # 15036, мы закончили со 100% совместимостью приложений с исходной поверхностью API .NET Framework System.Net.Http 4.0 и 100% совместимостью приложений при использовании WebRequestHandler .

С точки зрения уровня поддержки новых свойств, добавленных к HttpClientHandler (которые являются частью .NET Core 1.1 и более поздних версий), следующее суммирует ожидаемое поведение этих новых свойств при запуске на целевом объекте net46. :

1) public bool CheckCertificateRevocationList
Бросает PlatformNotSupportedException

2) публичный X509CertificateCollection ClientCertificates
Реализовано

3) общедоступные ICredentials DefaultProxyCredentials
Реализовано

4) публичный int MaxConnectionsPerServer
Реализовано против текущей логики ServicePoint

5) public int MaxResponseHeadersLength
Реализовано

6) публичный IDictionaryСвойства
Реализовано

7) public FuncServerCertificateCustomValidationCallback
Реализовано, за исключением того, что первый параметр всегда равен нулю из-за невозможности сопоставить внутренний HttpWebRequest с HttpRequestMessage

8) общедоступные протоколы SslProtocols SslProtocols
Бросает PlatformNotSupportedException

Ух! Спасибо ребята!

У кого-нибудь была возможность проверить биты @davidsh ? Мы действительно приветствовали бы некоторую сквозную проверку семи сценариев, на которые намекали в этой теме.

Пока нам удалось проверить

Как только мы его получим, мы перейдем к переносу изменений в ветку 1.1 и выпустим патч - надеюсь, на следующей неделе.

Я пройду тест на этой неделе. Меня только что втянули в эскалацию, поэтому я не могу начать в течение 1-2 дней, предположительно.

@dluxfordhpf спасибо! Ценю твою помощь.

Я только что установил в свой проект 4.4.0-beta-24913-02. Кажется, это помогает моему делу.

Кейс: самостоятельный хостинг ASP.NET Core из службы Windows, работающей на полной платформе 4.6.2. зависимость NETStandard.Library 1.6.1 заставляет меня использовать System.Net.Http 4.3.0.

По моему опыту, поток myget очень медленный. Установка System.Net.Http 4.4.0-beta-24913-02 заняла несколько минут
OK https://dotnet.myget.org/F/dotnet-core/api/v3/registration1/system.net.http/index.json 82079ms
OK https://dotnet.myget.org/F/dotnet-core/api/v3/registration1/system.net.http/index.json 93813ms

Спасибо @ annemartijn0 за подтверждение и за описание сценария!

В настоящее время этой странице требуется от пяти до семи минут, чтобы вернуть результат:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

Почему Microsoft передает жизненно важную инфраструктуру на аутсорсинг этим маленьким теневым компаниям и маленьким глупым сайтам? Вы действительно решили связать свой бизнес И мой бизнес с компанией в Бельгии под названием Tech Tomato?

В любом случае ... У меня уже был канал myget, но он не вытаскивал эту библиотеку, пока я не перезапустил Visual Studio, не нажал кнопку «обновить» где-то в диалоговом окне, а затем перезапустил Visual Studio во второй раз. В настоящее время я набираю это, пока Visual Studio 2015 пытается восстановить мои пакеты.

Обновление: Visual Studio все еще работает, но наконец-то появилось мое обновление страницы myget. Он показывает, наверное, дюжину загрузок этой версии библиотеки в день. Между тем Visual Studio резюмирует это как «System.Net.Http - 75,8 К скачиваний». Я всегда предполагал, что эта статистика говорит мне не то, но вот отличный пример того, почему это не то, что я хочу. Как минимум, пожалуйста, сообщите мне текущий статус версии по сравнению с резюме, чтобы я случайно не стал альфа-тестером без явного участия в безумии в этот абсурдный момент в истории .NET.

Спустя 5 часов я все еще не могу попробовать этот патч:

Attempting to gather dependency information for package 'System.Net.Http.4.4.0-beta-24913-02'
with respect to project '...', targeting '.NETFramework,Version=v4.6.1'

Через пять минут...

Package 'System.Net.Http 4.4.0-beta-24913-02' is not found in the following primary source(s):
'https://dotnet.myget.org/F/dotnet-core/api/v3/index.json'. Please verify all your online package
sources are available (OR) package id, version are specified correctly.

.NET - это пожар в шинах.

Да ладно тебе @chadwackerman . Вы _опубликовали_ их бета / альфа / непроизводственный канал, поэтому это означает, что вы готовы исключить проблемы и т. Д. Тем не менее, я использую myget целую вечность (платная подписка) и у меня очень мало проблем с Это. Так что, может быть ... может быть ... это может быть ваш компьютер / сетевое соединение / что угодно? (У меня было несколько действительно больших побед, используя MyGet за последние 12+ месяцев).

.NET - это сейчас не огонь из шин. Конечно, есть кучи сыра, которые перемещаются, и множество движущихся частей и прочего, что может (и действительно) выйти из строя. Но есть масса людей, которые делают отличные вещи с выпущенными версиями RC и RTM. Я лично решил использовать только публичные релизы - даже не BETA или RC больше. Так что мои ожидания таковы: меньше проблем, но придется ждать дольше. Так что, если вы находите некоторые из этих вещей действительно разочаровывающими для вас - возможно, просто подождите немного дольше, чтобы некоторые из этих разработок достигли статуса RTM.

Команда corefx (и другие участники в мире .NET-core) проделала отличную работу, и это отличный прием в отношении перехода на github / open-and-transparent по сравнению с bad-ole-Balmer-day, так что давайте все стараются оставаться позитивными и полезными для тех, кто поддерживает репо. Все здесь люди и все просто пытаются сделать мир лучше: по байту за раз.

@chadwackerman Похоже, сейчас myget feed страдает. Я не уверен на 100%, как работает myget, но я думаю, что если у вас есть выделенный хост ("dotnet.myget.org"), тогда каналы фактически арендуются и имеют ограничения QOS.

Переход сюда показывает, что пакет существует, но его появление требует времени: https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

@PureKrome Я бывший менеджер разработчиков Microsoft, которого попросили проверить эту сборку (см. Выше). После личного распространения этой ошибки внутри компании, потому что никто из команды .NET даже не знал об этом. И теперь они не могут отправить мне чертов двоичный файл.

Я узнаю пожар в шине, когда вижу его. Раньше я зарабатывал себе на жизнь выпуском их для Microsoft.

@chadwackerman Я понимаю ваше недовольство проблемами с фидом. Однако обзывание («глупые маленькие сайты» и «теневые маленькие компании») не в порядке.
Tech Tomato основан / управляется квалифицированными специалистами: @maartenba , @xavierdecoster , нынешний сотрудник MS; в стране (к которой я неравнодушен), которая поощряет инновации. Название компании вряд ли имеет отношение к делу, и то, что компания была основана в Бельгии, показывает, что команда .NET Core ищет решения не только в Редмонде, штат Вашингтон.
Надеюсь на ваш конструктивный вклад в решение этой проблемы.

Контент редактировал модератор

Отчет о Кодексе поведения был отправлен против некоторых комментариев в этой ветке, и в результате мы удалили некоторые материалы, которые были сочтены нарушающими этот код. Если у вас есть какие-либо вопросы или опасения по этому поводу, отправьте электронное письмо по адресу [email protected].

@chadwackerman: ваша бывшая должность в компании не дает вам права кого-либо

Эй , люди - Мартин из .NET Foundation здесь, хотел объяснить это .

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

А пока сохраняйте профессиональный тон и воздерживайтесь от комментариев, которые могут быть восприняты как личные нападки на других. Я намеренно не обращал внимания на внесенные правки, поскольку хотел сохранить некоторую силу чувств и не подвергать чрезмерной дезинфекции вещи, но, пожалуйста, сохраняйте вежливость.

Кто-нибудь еще пытался связаться с Tech Tomato? Нет ответа на мои запросы.

Вот как это будет выглядеть, если вы попытаетесь выполнить реальную работу по сортировке странных предупреждений о сборке после добавления канала:

Attempting to gather dependency information for package
'System.Net.Http.4.4.0-beta-24913-02' targeting '.NETFramework,Version=v4.6.1'
Gathering dependency information took 1.55 min

Attempting to gather dependency information for package 
'Microsoft.Extensions.Configuration.Json.1.1.0' targeting '.NETFramework,Version=v4.6.1' 
Gathering dependency information took 2.2 min

... и так далее.

И эта ссылка все еще занимает 5+ минут, чтобы отобразить страницу:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

То, что это а) еще не исправлено, б) игнорируется сообществом и в) терпимо для команды .NET в рамках повседневной разработки, служит усилению очевидных недостатков в процессе, инструментарии, культуре и управлении, которые привели к этой ошибке. Начнем с - плюс сама ошибка игнорировалась в течение нескольких месяцев, пока я лично не поднял ее внутри компании.

Я с нетерпением жду вскрытия, обещанного @karelz .

Привет, Чад,

Мы смотрим на время загрузки страницы. Время восстановления NuGet ненормальное. Если возможно, вы можете связаться с нами (MyGet) через службу поддержки на MyGet.org, указав используемую версию NuGet.exe, а также трассировку с включенным переключателем -Verbosity Detail? Это определенно поможет нам выявить любые проблемы с производительностью.

Благодаря!

Версия хоста консоли диспетчера пакетов 3.5.0.1996

Я посмотрю на получение журналов из командной строки по мере того, как Visual Studio переходит из стабильного состояния в нестабильное, как только я добавлю канал myget.org. И как только происходит ошибка при извлечении пакета, все переворачивается.

ps @karelz : огонь в шинах.

Можете ли вы попробовать эту командную строку, используя последнюю версию NuGet.exe (каждую ночь) с

Точная команда: NuGet.exe install System.Net.Http -Version 4.4.0-beta-24913-02 -Verbosity Подробно

Это также должно выводить все промежуточные действия загрузки. Благодаря!

@maartenba :

В отправленной вами ссылке "последний" указывает на https://dist.nuget.org/win-x86-commandline/latest/nuget.exe. Это версия, которая у меня уже есть, поэтому я не думаю, что это вечерняя.

Я загрузил ночной пакет NuGet.CommandLine.4.0.0-rtm-2254.nupkg, запустил на нем программу nuget.exe и не смог загрузить файлы с myget.org. К вашему сведению: 1,5 секунды, чтобы вернуть 404 с dotnet.myget.org.

Если это неправильный способ установки ночной сборки или локального пакета, сообщите об этом. Вы можете написать мне на это имя пользователя в Gmail, если вы предпочитаете использовать это в автономном режиме.

Все еще рад помочь, но ... вау. Вещи действительно должны двигаться в направлении простоты, а не я устраняю неполадки вторичного хоста пакета для первичного хоста пакета, используя ночное отключение диспетчера пакетов, который, несмотря на версию 4.0.0-rtm, каким-то образом имеет пять различных ручных методов для обновляется на своей странице распространения, каждая из которых требует ручного вмешательства пользователя.

ps @karelz ... да ладно. :)

Полностью согласен, но журналы были бы очень полезны для определения узкого места (будь то хост вторичного пакета, сам клиент, сумасшедший узел CDN, космические лучи, ...). Мы свяжемся с вами в автономном режиме, чтобы узнать, сможем ли мы это выяснить. Очень признателен за вашу помощь в этом.

Я сам заметил, что myget.org работает довольно медленно, но я смог успешно установить рассматриваемый пакет в «разумное» время (в общедоступной сети Wi-Fi).

OK https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.4.0-beta-24913-02 971ms
Installing System.Net.Http 4.4.0-beta-24913-02.

Мы обязательно должны изучить общую медлительность myget.org, но, вероятно, за пределами этой проблемы - в конце концов, это не типичный сценарий для клиентов. @maartenba, где лучше всего это обсудить?
Здесь (на этой конкретной проблеме) давайте сосредоточимся на том, как разблокировать сквозную проверку, например, используя некоторые творческие обходные пути.
Также мне интересно, были ли другие люди заблокированы так сильно, как @chadwackerman , или опыт @chadwackerman чрезвычайно плох по сравнению с другими.

@chadwackerman, учитывая, что основная цель здесь - проверить сквозной сценарий, мне интересно, можете ли вы предоставить шаги своего сценария? Кто-то здесь (кто не так сильно заблокирован использованием myget.org, как вы) может завершить проверку в таком случае. Это должно уменьшить вашу боль и потерю времени на вашу сторону. Конечно, при условии, что это выполнимо и выполнимо дешево с вашей стороны.

Последняя альтернатива, которой я бы хотел избежать, - полностью пропустить проверку вашего сценария - если мы получим несколько проверенных других сквозных сценариев, мы можем быть в порядке (при худшем сценарии, когда

@karelz, общающийся с Чадом в автономном режиме, сообщит здесь, как только мы

Общие факты:

• Канал myget.org используется для ежедневных сборок, CI, рабочих процессов разработки и т. д. Так что ежедневно он сильно загружается. Ни одна из этих проблем с производительностью не проявляется в этих сценариях (когда они возникали в прошлом, мы действовали по ним, потому что они влияли на рабочий процесс наших разработчиков - мы увеличили время синхронизации с 30-60 минут до <5 минут за последние несколько месяцев). Насколько я понимаю, кто-либо из команды .NET или сообщества редко использует канал myget в VS - что IMO объясняет, почему плохая производительность осталась незамеченной в этом сценарии.
• Эта проблема была передана мне коллегой в этой ветке 9 декабря 2016 года - поэтому я присоединился к обсуждению здесь. Мне не известно о какой-либо другой внутренней эскалации. Учитывая, что я постоянно продвигаю эту проблему внутри нескольких команд (почти ежедневно), я думаю, что я в курсе всех событий, связанных с этой проблемой.

@karelz Да, я

С тех пор я подтвердил, что MyGet.org плохо себя ведет на машинах нескольких друзей как на Восточном, так и на Западном побережье. Моя - это недавняя чистая установка Visual Studio 2015, без надстроек и определенно без ReSharper. Обратная связь с пользователем и обработка ошибок в Visual Studio оставляет желать лучшего. Даже здесь другие пользователи сообщают о подобных задержках. Я оставлю это сейчас, чтобы освободить поток, но давайте не будем притворяться, что MyGet не работает, и вся система упаковки NuGet (и способность NuGet обновлять себя) не имеет слабого запаха горящей резины, а также не является фактор, способствующий этой ошибке. Первоначально как часть основной причины и даже сегодня как часть попытки протестировать и отправить исправление.

Не уверен, стоит ли нам продолжать обсуждать это в этой ветке или открыть для этого другую ветку. В любом случае: отчет о состоянии!

Мы связались с @chadwackerman по электронной почте - спасибо, Чад за отправленный журнал!

О «медлительности» - предварительное профилирование говорит нам, что это вызвано количеством версий пакета и влиянием этого факта на размер загружаемых данных протокола. Например, для некоторых пакетов требуется 4 МБ данных JSON для загрузки и анализа для сбора метаданных. Это вызывает большой всплеск использования памяти в клиенте NuGet и необходимость синтаксического анализа загруженных данных JSON - определенно есть место для улучшения, хотя ночные журналы клиента 4.0.0, кажется, ведут себя лучше.

На стороне MyGet мы будем реализовывать разбиение на страницы для этих блобов протокола, чтобы уменьшить размер загрузки по протоколу. Это может занять неделю. Мы также будем профилировать сервер и клиент по этим запросам и посмотреть, есть ли место для оптимизации с обеих сторон.

Мы также стремимся ускорить время загрузки страницы (но это вторично, приоритетом является быстрая установка / восстановление).

После нескольких часов экспериментов я смог перейти на System.Net.Http 4.4.0-beta-24913-01 без сбоев Visual Studio. Затем я попытался обновить систему с 24913-01 до 24913-02 и получил правильную ошибку вместо сбоя.

Сейчас 2017 год, и обновление ночной сборки основного HTTP-компонента для всей системы с «сборки за понедельник» до «сборки за вторник» занимает более пяти минут времени настенных часов на 8-Core i7 и требует более 4 ГБ оперативной памяти.

Рассматриваемый проект представляет собой веб-задание (приложение командной строки с ребрендингом), состоящее из 27 строк кода.

Интересно, что @karelz заявляет, что это отлично работает для всей команды .NET, и у него нет никаких проблем с

Я смог успешно установить рассматриваемый пакет в «разумное» время (в общедоступной сети Wi-Fi).
https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.4.0-beta-24913-02 971 мс

Вот несколько альтернативных фактов:

Попытка собрать информацию о зависимостях для пакета 'System.Net.Http.4.4.0-beta-24913-02' в отношении проекта 'webjob', нацеленного на '.NETFramework, Version = v4.6.1'
Сбор информации о зависимостях занял 4,22 мин.
Попытка разрешить зависимости для пакета 'System.Net.Http.4.4.0-beta-24913-02' с DependencyBehavior 'Lowest'
Разрешение действий по установке пакета 'System.Net.Http.4.4.0-beta-24913-02'
Устранены действия по установке пакета System.Net.Http.4.4.0-beta-24913-02.
System.OutOfMemoryException: возникло исключение типа «System.OutOfMemoryException».
в Newtonsoft.Json.Linq.JContainer.ReadContentFrom (JsonReader r)
в Newtonsoft.Json.Linq.JContainer.ReadTokenFrom (читатель JsonReader)
в Newtonsoft.Json.Linq.JObject.Load (читатель JsonReader)
в NuGet.Protocol.HttpSource. <> c.b__15_0 (Поток потока)

Да, ребята, не могли бы вы переместить эту проблему MyGet / NuGet в новую проблему? Это не имеет отношения к оригинальному изданию.

@onovotny - Вы могли бы рассмотреть возможность повторного открытия вопроса на. Этот выпуск теперь очень длинный, поэтому удобство использования проблемы было снижено.

@richlander вместо того, чтобы

Протестируйте все ~ 7 сквозных сценариев, о которых сообщает сообщество (обратитесь за помощью к сообществу, укажите шаги по использованию основных пакетов на myget)

Каковы 7 сценариев? Всем может помочь?

@richlander Я был бы рад снова открыть проблему, вы просто ищете, чтобы я клонировал ее с обновлениями

Мой вариант использования работал с API службы хранилища Azure, который последний раз работал в версии 4.0.1-rc2-24027. Похоже, сейчас это работает. Я провел только быстрый тест, так как обновление всех пакетов в моих проектах из MyGet заняло около 20 минут.

@onovotny Не открывать повторно. У нас есть импульс, и мы находимся в дюймах от хотя бы частичного разрешения. Тема ошеломляет для всех, кто только что присоединяется, но, как и любая другая давно нерешенная проблема, которая выявляет более глубокие проблемы, так и должно быть. GitHub - отстой для подобных вещей.

Я убедился, что новый двоичный файл совместим с одним локальным приложением. В этом нет ничего удивительного. Затем я попытался вырезать и вставить эти зависимости в свой проект веб-задания, но не смог заставить его работать в Azure. Webjob загружается нормально, но при запуске не удается загрузить System.Net.Http. Очевидно, это моя вина, и я знаю, как ее исправить. Но я почти вернулся к тому месту, где был, когда впервые открылась эта ошибка: настраиваемое переназначение привязки, и когда я касаюсь NuGet, весь ад вырывается, я теряю огромное количество времени, и мой проект проходит все тесты локально, но ломается во время выполнения после развертывания .

Итак, наши сценарии:

1. Зависимый пакет (Raven.Database) использует WebRequestHandler, который, как сообщается в этой проблеме, ломался во время выполнения.
2. В нашем коде используется новый тип и свойства HttpClientHandler.

Раньше я пробовал исправления перенаправления привязки, но это приводило к спорам, затем я использовал хаки (внедрение отражения, дублирование и изменение стороннего кода) для решения проблем.

Я обновился до бета-версии и удалил весь код взлома, и все (наше приложение, от браузера до базы данных), похоже, работает локально! Я еще не пробовал код на платформе Azure, поэтому я подтвердю еще раз, когда это будет сделано, но я считаю это значительным прогрессом.

Кроме того, при обновлении пакетов я обнаружил, что можно использовать консоль диспетчера пакетов Visual Studio и использовать эту команду для обновления пакетов (вместо добавления другой конфигурации канала и последующего использования пользовательского интерфейса, что невероятно болезненно):

Update-Package System.Net.Http -Version 4.4.0-beta-24913-02 -Source https://dotnet.myget.org/F/dotnet-core

На обновление 20 проектов ушло 6 минут 53 секунды.

Обратите внимание, что во всех наших проектах автоматически сгенерировалось следующее перенаправление привязки, мне вообще не нужно было возиться с перенаправлениями привязки:

    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />
      </dependentAssembly>
    </assemblyBinding>

Почти пора дать пять!

@jahmai Когда я использовал эту командную строку, она не обновляла мою ссылку с 4.0 до 4.2 и не добавляла необходимые флаги копирования. Убедитесь, что они установлены для System.Net.Http и зависимостей, и он должен нормально работать в Azure.

Наш сценарий - прямая зависимость от типов в System.Net.Http.
Я тестировал Update-Package System.Net.Http -Version 4.4.0-beta-24913-02 -Source https://dotnet.myget.org/F/dotnet-core на одном проекте, и пока он работает хорошо. Это очень хорошие новости.
Обновление Забыл упомянуть, что перенаправления привязки с 4.0.0.0 на 4.2.0.0 применялись автоматически.

Что касается проблем с Nuget / MyGet, я получил следующий результат для этого единственного проекта:

Сбор информации о зависимостях занял 37,47 секунды.
Выполнение действий nuget заняло 35,15 секунды
Истекшее время: 00: 01: 14.7537429

Обратите внимание, что я нахожусь в часовом поясе UTC +01: 00, не знаю, когда MyGet получает больше всего трафика.

@pollax Спасибо. Мы нашли проблему (см. Мой последний комментарий выше) - комбинация клиент + сервер. Работаем над улучшением.

Я могу подтвердить, что использование бета-библиотеки System.Net.Http от MyGet сработало для моего сценария:

• Консольное приложение .NET 4.6 с зависимостью от библиотеки, использующей System.Net.Http

Для загрузки пакета nuget из MyGet потребовалось около 90 секунд, а параметр bindingRedirect в app.config был применен правильно.

Я рад помочь протестировать больше сценариев, если они где-то были описаны.

Интересный побочный эффект: добавление 4.4.0-бета-версии библиотеки .NET только для Windows прервало развертывание приложения .NET Core в Linux.

«Восстановление dotnet» жестко запрограммировано на время извлечения пакета 60 секунд. И нет флага для выбора только определенной платформы, например, поддерживаемой dotnet publish. Итак, для кроссплатформенной библиотеки ваш крошечный рабочий узел Linux без необходимости загружает кучу двоичных файлов Windows, а затем выходит из строя и терпит неудачу, когда попадает в MyGet. Забавно, что проблема нехватки памяти, которая приводит к сбою Visual Studio на машине 32 ГБ, не влияет на рабочий Linux 0,75 ГБ, потому что вместо этого он заменяется до смерти.

Да, я зарегистрировал это в другом месте. И да, это относится к этой ошибке, даже если вы ее еще не видите.

Спасибо всем, кто помог нам проверить сценарии! На данный момент мы получили 5 подтверждений - см. Подробный список со ссылками в самом верхнем посте. Я считаю это достаточно хорошей проверкой, чтобы перейти к следующим этапам.

• [4.a.ii] Я все еще ищу анализ NuGet.
• [5.a] Я попрошу @davidsh подготовить PR для ветки release / 1.1.0.

• [5.b] Я готовлю процесс к выпуску (нам нужно одобрение на уровне директора, но, учитывая влияние на клиентов, я не ожидаю никакого сопротивления).

• Я готовлю официальную информацию о выпуске патча - список всех технических критических изменений и обходных путей (спасибо

Если за это время кто-то обнаружит какую-либо проблему (связанную с этой конкретной проблемой), сообщите об этом как можно скорее. Скрещенные пальцы.

@onovotny - Похоже, проблема сейчас продвигается вперед, так что давайте продолжим ее. Приятно видеть, что люди добиваются положительных результатов.

@karelz Вы можете

Проблема восстановления dotnet возобновлена ​​на https://github.com/NuGet/Home/issues/2534 , Contributor Covenant исправил обратный канал, шины выкинуты на https://github.com/Azure/azure-storage-net/issues/372 , MyGet отправленные журналы, дополнительные журналы производительности, запрошенные на https://github.com/dotnet/cli/issues/5328 , и я купил огромный мешок попкорна для посмертного обсуждения.

Спасибо @chadwackerman за помощь и подтверждение! Приносим извинения за проблемы, с которыми вы столкнулись в пути.
Я обновил самый верхний пост.

Из моего списка выше:

Я готовлю официальную информацию о выпуске патча - список всех технических критических изменений и обходных путей (спасибо

Я добавил информацию в самый верхний пост - см. В разделе «Влияние изменения - Критические изменения» список критических технических изменений (4), для каждого из которых есть обходной путь.

На библиотеки NuGet повлияло техническое изменение (описанное в самом верхнем посте) - к счастью, "всего" 4 библиотеки NuGet, которые используют любой из этих новых API:

System.Private.ServiceModel_4.3.0

• https://www.nuget.org/packages/System.Private.ServiceModel/
• Автор: dotnetframework
• Загрузок: 11K (последняя версия) / 800K (всего)
• Описание: Пакет внутренней реализации не предназначен для непосредственного использования. Пожалуйста, не ссылайтесь напрямую. Обеспечивает реализацию пакетов System.ServiceModel.
• Ноты:
• Статус: пакет не затронут - @zhenlan @mconnew из команды WCF подтвердил, что они используют свойства только в сборках .NET Core. На рабочем столе они возвращаются к встроенным двоичным файлам рабочего стола.

Consul_0.7.2.1

• https://www.nuget.org/packages/Consul/
• Имя: Консул
• Автор: https://www.nuget.org/profiles/highlyunavailable
• Скачиваний: 500 (последняя версия) / 65K (всего)
• Описание: https://github.com/PlayFab/consuldotnet/blob/master/CHANGELOG.md
• Ноты:
  
  
  
  • 2 использования: https://github.com/PlayFab/consuldotnet/search?utf8=%E2%9C%93&q=ServerCertificateCustomValidationCallback
  
  
  • Проблема подана на GitHub: https://github.com/PlayFab/consuldotnet/issues/79
  
  
  • Электронное письмо отправлено автору через nuget.org
  
  
• Статус: пакет не затронут (проблема с GitHub https://github.com/PlayFab/consuldotnet/issues/79 закрыта)

Осьминог.Client_4.6.1

• https://www.nuget.org/packages/Octopus.Client/
• Автор:
  
  
  
  • https://www.nuget.org/profiles/paulstovell
  
  
  • https://www.nuget.org/profiles/OctopusDeploy
  
  
• Скачиваний: 250 (последняя версия) / 55K (всего)
• Описание: Нет
• Ноты:
  
  
  
  • Проблема, зарегистрированная на GitHub: https://github.com/OctopusDeploy/OctopusClients/issues/121
  
  
  • Электронное письмо отправлено на псевдоним службы поддержки:
  
  
  • Электронное письмо отправлено авторам через nugget.org
  
  
• Статус: пакет не затронут (подробности в проблеме GitHub https://github.com/OctopusDeploy/OctopusClients/issues/121)

Geotab.Checkmate.ObjectModel_5.7.1701

• https://www.nuget.org/packages/Geotab.Checkmate.ObjectModel/
• Имя: Geotab SDK
• Автор: https://www.nuget.org/profiles/neilcawse
• Скачиваний: 150 (последняя версия) / 10K (всего)
• Описание:
  
  
  
  • Библиотека SDK для доступа к базам данных клиентов MyGeotab
  
  
  • Смотрите полный список изменений на https://my.geotab.com/sdk/default.html#/whatsNew
  
  
• Ноты:
  
  
  
  • Электронное письмо отправлено автору (генеральному директору geotab.com) через nugget.org
  
  
• Статус: с владельцем связались, ожидает ответа

Приносим извинения за неудобства всем авторам пакетов.

При сбое / замене Visual Studio / NuGet в Linux: причина этого в том, как работает протокол NuGet. Я задокументировал результаты этого выпуска: https://github.com/NuGet/Home/issues/4448

На стороне MyGet после выходных мы развернем изменение (в настоящее время тестируемое, ETA в производстве, понедельник, 7 февраля), которое облегчит эту проблему на стороне сервера.

Исправление на стороне MyGet уже доступно. Должен нормально работать в Visual Studio. При использовании NuGet.exe обязательно используйте NuGet.exe, встроенный в https://dotnet.myget.org/F/nuget-build/api/v2/package/NuGet.CommandLine (4.0 nightly) - 3.5 похоже, не может определить зависимости (но не всегда). Зарегистрированная ошибка: https://github.com/NuGet/Home/issues/4512

Спасибо за глубокое погружение в этот @maartenba. Никогда не недооценивайте влияние, которое может иметь даже незначительное исправление инструмента!

Интересно, что вся команда .NET могла пропустить как сбой Visual Studio, так и проблему NuGet.

Однажды я попросил группу из более чем 80 разработчиков Microsoft поднять руку, если у кого-то возникают проблемы с установкой точек останова в отладчике. У меня две руки. Компилятор изменил формат символа, вы не можете собрать проект без последней версии компилятора, но отладчики еще не обновились.

В течение нескольких месяцев никто не мог установить точку останова. На двух платформах невозможно было даже получить трассировку стека! Меня вызывают в лабораторию сборки в час ночи, потому что я единственный человек вокруг, получаю полный экран сборки для процессора, для которого я даже не видел документации, вытаскиваю трассировку, и отладчик вылетает в отладчик.

Когда вы меняете формат проекта во время изменения кода, который анализирует формат проекта, пока вы загружаете новую версию диспетчера пакетов, которая подключается к новой версии Visual Studio, - такие результаты. Смертный может иметь дело только с таким количеством изменений одновременно, и поэтому разработчики продолжают бросать мяч повсюду. И мы, и они!

Если кому-то нужен простой скрипт PowerShell для исправления bindingRedirect во всех app.config, вот он. Вероятно, это не лучшее решение, но прямо сейчас у меня есть проект с множеством подпроектов веб-заданий, и это действительно разочаровывает, вручную изменять все привязки файлов после обновления некоторого пакета.

param(
    [string]$SourceDirectory,
    [string]$Package,
    [string]$OldVersion,
    [string]$NewVersion
)

Write-Host "Start fixing all app.config"

[array]$files = get-childitem $sourceDirectory -Include app.config App.config -Recurse | select -expand FullName
foreach ($file in $files)
{
    Write-Host $file
    $xml = [xml](Get-Content $file)
    $daNodes = $xml.configuration.runtime.assemblyBinding.dependentAssembly
    foreach($node in $daNodes)
    {
        if($node.assemblyIdentity.name -eq $package)
        {
            $updateNode = $node.bindingRedirect
            $updateNode.oldVersion = $OldVersion
            $updateNode.newVersion =$NewVersion
        }
    }
    $xml.Save($file)
}

Write-Host "Done"`

Пример использования:
./scripts/FixAppConfig.ps1 -SourceDirectory "--project-path--" -Package "System.Net.Http" -OldVersion "0.0.0.0-4.3.0.0" -NewVersion "4.0.0.0"

Когда это снова станет публичным? :)

Наше изменение попало во вторник в ветку release / 1.1.0 - пакет версии 4.3.1. Вчера все пакеты в ветке были переведены на стабильную версию (независимые усилия, но нам тоже помогает :)).
@davidsh проведет проверку работоспособности на фиде myget (ETA: сегодня), затем мы попросим сообщества провести здесь последнюю проверку (ETA: сегодня, EOD). После окончательной проверки этой сборки мы отправим пакет в NuGet. Я ожидаю, что это займет меньше недели.

У нас была задержка в работе и общении, потому что нам нужно было убедить судоремонтный завод, почему это лучшее и единственное решение.
Вдобавок к этому мы готовим план (основанный на обратной связи с отделением доставки), чтобы полностью прекратить поставки этого незапланированного пакета в .NET Standard 2.0 и передать все функции встроенной среде рабочего стола (функциональность .NET Core останется неизменной) - т.е. перенаправления привязки не потребуются, если вы ориентируетесь на .NET Standard 2.0. Как только я получу подробную информацию о влиянии на все сценарии, я обновлю эту ветку (через 1-2 недели).

Это долгожданная новость, которая упростит использование netstandard2.0.

@davidsh проверил пакет 4.3.1 из ветки выпуска (предупреждение: myget был очень медленным для него - 5 минут)
Вот шаги для проверки:

Пожалуйста, попробуйте последние пакеты в ленте разработчиков MyGet. Вы захотите использовать последнюю СТАБИЛЬНУЮ (не предварительную) сборку пакета System.Net.Http.dll - 4.3.1 :
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

Вы можете использовать пакеты каналов разработки, изменив исходные каналы пакетов NuGet с помощью инструментов командной строки или Visual Studio.

Инструкции:

Командная строка:
Добавьте следующее в nuget.config в разделеэлемент:

<add key="myget.org dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />

Visual Studio:
В VS Инструменты-> Параметры-> Диспетчер пакетов Nuget-> Источники пакетов-> Добавить в разделе Источник используйте этот URL-адрес https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

В любом случае убедитесь, что вы указали канал MyGet dev в качестве первого канала в списке.

[РЕДАКТИРОВАТЬ]
Ожидайте перенаправления привязки для 4.1.1.0 в вашем файле конфигурации:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>

Я обновил верхний пост «План выполнения» следующими шагами:

• 5.c Окончательная / последняя проверка (большинства) ~ 7 сквозных сценариев - люди, которые помогали раньше (или кто-либо еще), не могли бы вы ответить, как только подтвердите краткое описание сценария? Благодаря! (мы почти там)
  
  
  
  • Копия: @ annemartijn0 @karelkrivanek @jahmai @pollax @MikeGoldsmith @chadwackerman @dluxfordhpf @onovotny
  
  
• 5.d Опубликуйте пакет на myget.org

Пытался проверить, но при установке этого пакета возникают ошибки.

Когда я сделал свою проверку, я сделал это с совершенно новым проектом.

Я подозреваю, что ошибка «Не удалось обновить перенаправления привязки» связана с понижением версии пакета и версии сборки. Ваш текущий проект, похоже, основан на пакетах из ветки [master]. System.Net.Http.4.4. * - это нумерация пакетов из ветки [master] (часть предварительной версии для .NET Core 2.0). У него есть версия сборки для System.Net.Http - 4.2. *.

Пакет System.Net.Http версии 4.3.1 является СТАБИЛЬНЫМ (не предварительным выпуском) пакетом и построен из обслуживающей ветви .NET Core 1.1 (совместим с обслуживающим выпуском .NET Core 1.1.1). Он содержит двоичный файл dll System.Net.Http с другой версией сборки.

Я думаю, что обнаруженная вами ошибка возникает, когда Visual Studio / NuGet пытается переписать ваши перенаправления привязки для измененной версии сборки System.Net.Http.

Итак, вы можете попробовать создать новое новое решение / проект. Или, возможно, удалите перенаправления привязки, а затем верните их.

К вашему сведению. Мой журнал установки моего пакета:

Attempting to gather dependency information for package 'System.Net.Http.4.3.1' with respect to project 'Net46HttpTest3', targeting '.NETFramework,Version=v4.6.1'
Gathering dependency information took 4.27 min
Attempting to resolve dependencies for package 'System.Net.Http.4.3.1' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'System.Net.Http.4.3.1'
Resolved actions to install package 'System.Net.Http.4.3.1'
Retrieving package 'System.Security.Cryptography.Encoding 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.Primitives 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.Algorithms 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.X509Certificates 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Net.Http 4.3.1' from 'CoreFx Dev Feed'.
  GET https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.3.1
Adding package 'System.Security.Cryptography.Encoding.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Encoding.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
  OK https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.3.1 302ms
Installing System.Net.Http 4.3.1.
Added package 'System.Security.Cryptography.Encoding.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Encoding 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.Primitives.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Primitives.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Primitives.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Primitives 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.Algorithms.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Algorithms.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Algorithms.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Algorithms 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.X509Certificates.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.X509Certificates.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.X509Certificates.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.X509Certificates 4.3.0' to Net46HttpTest3
Adding package 'System.Net.Http.4.3.1' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Net.Http.4.3.1' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Net.Http.4.3.1' to 'packages.config'
Successfully installed 'System.Net.Http 4.3.1' to Net46HttpTest3
Executing nuget actions took 2.41 sec
========== Finished ==========
Time Elapsed: 00:06:40.8451462

Хм, при тестировании запуталась. Я обновился до 4.3.1 и получил следующее перенаправление привязки в моем web.config.

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>

Ожидается?
Возможно, я что-то пропустил ранее в потоке, или, может быть, это одна из тех запутанных ситуаций несовпадения версии пакета и версии dll.
Я также удалил пакет, удалил перенаправления привязки, а затем переустановил, и я получил тот же результат.

Сборка и запуск Works On My Machine ™ ️.

Я, кстати, не совсем понимаю, почему эта версия упала с 4.4 до 4.3.1, но ладно.

Номер версии упал, потому что версия 4.4 будет последней, но она все еще находится в стадии предварительного выпуска и будет поставляться как часть .NET Core 2.0. @karelz попросил людей сначала протестировать этот пакет, потому что исправление было первым.

Пакеты 4.3. * Основаны на RTM .NET Core 1.1. И будет сервисный выпуск этого. Итак, обновленный пакет, основанный на этой кодовой базе, - 4.3.1 для System.Net.Http (поскольку пакет .NET Core 1.0 был 4.3.0 для System.Net.Http.

Возможно, я что-то пропустил ранее в потоке, или, может быть, это одна из тех запутанных ситуаций несовпадения версии пакета и версии dll.

Да, это сбивает с толку. Версия пакета NuGet отличается от версии двоичного файла сборки .NET.

Для пакета NuGet System.Net.Http 4.3.1 он действительно содержит двоичный файл System.Net.Http с версией сборки 4.1.1.0. Итак, вы получаете правильные результаты.

Спасибо @pollax за проверку вашего сквозного сценария (верхний пост обновлен).
Жду еще нескольких проверок, прежде чем мы сможем отправить его в качестве окончательного исправления на nuget.org ... почти готово ...

Приношу свои извинения за то, что мы пропустили перенаправление привязки в инструкциях (я не осознавал, что мы автоматически подгоняем версию сборки из-за возможного GAC'инга, но это имеет смысл).
Также извиняюсь за то, что myget заставляет вас использовать все пакеты из myget - я слежу за людьми внутри, чтобы узнать, есть ли у нас шаги для получения только одного пакета из myget. По крайней мере, для будущих проверок.

@davidsh, не могли бы вы скоординировать @leecow / @weshaggard опубликовать пакет на nuget.org. Благодаря!

Эй, ребята,

Немного не по теме, но я просто хотел поблагодарить команду здесь. Этот вопрос был очень активным, и реакция иногда была враждебной. Несмотря на враждебность, я чувствую, что команда разработчиков отлично справилась с этим.

Спасибо за поддержку, ребята, продолжайте в том же духе. Ошибки случаются. Спасибо, что исправили, я понимаю, что это требует времени.

Вот еще одно подтверждение, что новая версия решает проблему.

Мы используем KeyVault, при переходе на 4.3.1 проблема была решена.

Привет, у меня проблема с SignalR. Но как мне получить System.Net.Http 4.3.1? Я вижу только 4.3.0 в
https://www.nuget.org/packages/System.Net.Http/

Упс, пропущенные сообщения о CoreFx - https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

Это устраняет мою проблему с SignalR.

Как отмечали другие, подача происходит очень медленно. Есть ли шанс получить 4.3.1 в нормальном канале nuget? Сейчас суббота в 13:30 и эй .... (8 минут ожидания депс)

Попытка собрать информацию о зависимостях для пакета 'System.Net.Http.4.3.1' в отношении проекта 'Translate \ Kumquat.Translate.Tests', нацеленного на '.NETFramework, Version = v4.6'
Сбор информации о зависимостях занял 5,85 мин.
Попытка разрешить зависимости для пакета System.Net.Http.4.3.1 с DependencyBehavior Lowest
Одно или несколько неразрешенных ограничений зависимости пакетов, обнаруженных в существующем файле packages.config. Для добавления или обновления пакетов необходимо разрешить все ограничения зависимостей. Если эти пакеты обновляются, это сообщение может быть проигнорировано, в противном случае следующие ошибки могут блокировать текущую операцию пакета: 'System.Net.Http 4.3.0'
Разрешение информации о зависимостях заняло 0 мс
Разрешение действий по установке пакета 'System.Net.Http.4.3.1'
Устранены действия по установке пакета System.Net.Http.4.3.1.

Попытка собрать информацию о зависимостях для пакета 'System.Net.Http.4.3.1' относительно проекта 'Dict \ Kumquat.Dict.CE.Tests', нацеленного на '.NETFramework, Version = v4.6'
Сбор информации о зависимостях занял 3,84 мин.
Попытка разрешить зависимости для пакета System.Net.Http.4.3.1 с DependencyBehavior Lowest
В существующем файле packages.config обнаружено одно или несколько неразрешенных ограничений зависимости пакетов. Для добавления или обновления пакетов необходимо разрешить все ограничения зависимостей. Если эти пакеты обновляются, это сообщение может быть проигнорировано, в противном случае следующие ошибки могут блокировать текущую операцию пакета: 'System.Net.Http 4.3.0'
Разрешение информации о зависимостях заняло 0 мс
Разрешение действий по установке пакета 'System.Net.Http.4.3.1'
Устранены действия по установке пакета System.Net.Http.4.3.1.

@karelz Сценарий API

Извините, что не ответил раньше.

@tofutim собирает зависимости медленно из-за большого количества метаданных, передаваемых по сети - https://github.com/NuGet/Home/issues/4448

Я понял это. Есть ли расчетное время прибытия на сайт nuget.org?

@davidsh Привет, Дэвид, это будет неделя, на которой 4.3.1 появится на nuget? У меня довольно сложный проект, и мне кажется, что время ожидания должно масштабироваться в зависимости от количества пакетов в проекте. Тем не менее, исправить это лучше, чем ничего. Полагаю, я могу где-нибудь скопировать nupkg.

Попытка собрать информацию о зависимостях для пакета «Kumquat.Translate.8.6.2» в отношении проекта «qi», нацеленного на «.NETFramework, Version = v4.6»
Сбор информации о зависимостях занял 8,76 мин.

Последний раз 8,76 мин.

@davidsh Это только что появилось в списке рассылки OwlMQ. Могу сообщить, что обновленный пакет это решает.

Большое спасибо команде за то, что опередили это. Отличная работа!

Спасибо за все проверки пакета.

Пакет System.Net.Http 4.3.1 переведен на NuGet.org.

https://www.nuget.org/packages/System.Net.Http/4.3.1

Хм, очень странно - клиент RavenDB теперь жалуется, что не может найти сборку 4.1.1

РЕДАКТИРОВАТЬ: Предостережение - Acme.Core ссылается на RavenDB.Client и Acme.Main ссылается на Acme.Core. VS2015 не будет копировать System.Net.Http как зависимость, но есть перенаправление привязки -> бум. Это ожидаемое поведение? Конечно, достаточно простое исправление ...

Закрытие проблемы как исправленной. Спасибо @davidsh и @CIPop за их работу!
Спасибо всем за терпение. И приносим свои извинения за задержку. Следующий шаг: вскрытие (как и было обещано) - пожалуйста, дайте мне ~ 2 недели, чтобы узнать все исторические подробности здесь ...

@georgiosd, не могли бы вы подать новую проблему и предоставить репродукцию? (в идеале, начиная с нового проекта)

@karelz спасибо!

К вашему сведению:

• Я обновил самый верхний пост со списком проверенных сценариев (на случай, если он когда-либо понадобится в будущем) и ссылкой на пакет.
• В будущем я планирую рассмотреть шаги по использованию только определенного пакета из myget вместо всего канала, чтобы обойти проблему получения всего самого свежего (а также проблемы с медленностью). Будем надеяться, что так скоро оно нам не понадобится.

@karelz быстрый вопрос: где мы найдем информацию о вскрытии, когда оно будет завершено. В этой ветке _или_ другую ветку / место?

@PureKrome Обязательно обновлю эту ветку - так всем уже заинтересованным проще получить уведомление. Также моя цель - не преуменьшить значение вскрытия и скрыть его от людей.
Скорее всего, я создам новый вопрос для обсуждения (как я и ожидал) ;-).
На высоком уровне я планирую осветить:

1. Как проблема попала в релиз? Как предотвратить такую ​​ситуацию в будущем?
2. Почему на исправление ушло 6 месяцев? Почему раньше это не рассматривалось / не сообщалось как серьезная проблема? Как распознать серьезные проблемы и отреагировать на них в более раннем будущем?
3. Другие проблемы (например, общение в целом)

Кроме того, если мы обнаружим, что что-то сломано / работает некорректно с 4.3.1 (например, @georgiosd , находка выше ), мы должны упомянуть об этом здесь для осведомленности, но вынести детали в отдельную проблему для облегчения обсуждения / последующих действий.

Спасибо @karelz (и команде MS). Тогда я останусь подписанным на эту тему. 👍

Продолжайте бороться, команда! 💯

Я также должен поблагодарить @ chadwackerman2

Еще раз поздравляю всех с устранением одной из самых досадных ошибок в истории .NET :)

@karelz рад сделать это, но мне интересно, является ли это каким-то образом ожидаемым поведением?

@georgiosd Не знаю - проще будет обсудить в отдельном выпуске ;-) (в т.ч. с привлечением нужных экспертов)

Спасибо за эту работу, @karelz

Я знаю, что опаздываю с вскрытием, мои извинения.
Я не забыл, я просто еще не дошел до этого из-за более высоких приоритетов (планирование / отслеживание 2.0, более глубокое изучение проблемы перенаправления привязки, которая также всплыла здесь - dotnet / runtime # 17770)
Я постараюсь закончить вскрытие в ближайшие 1-2 недели.

Привет, молодцы, все, кто участвует в разрешении этой проблемы. Не могу сказать, что я понимаю все гайки и болты, но я до сих пор не понимаю, почему это произошло только тогда, когда мы обновили наше решение с VS 2015 Update 3 до VS 2017. Рассматриваемым решением был набор проектов ASP.Net Core, ориентированных на фреймворк .net 4.6. Проблема была вызвана нашим использованием Azure KeyVaultClient.

Спасибо донал

Привет @karelz , я занимаюсь исследованием и работаю две ночи подряд, но я не могу это исправить. Все мои пакеты System.Net.Http были обновлены до версии 4.3.1, но по-прежнему получают ту же ошибку. Пожалуйста, помогите мне, я не знаю, что еще попробовать и куда пойти. Благодаря!

FileNotFoundException: не удалось загрузить файл или сборку System.Net.Http, Version = 4.1.1.0, Culture = нейтральный, PublicKeyToken = b03f5f7f11d50a3a. Система не может найти указанный файл.

Здесь мой .csproj

netcoreapp1.1

$ (PackageTargetFallback); переносной net45 + win8 + wp8 + wpa81;

aspnet-IbmVcaCore-5aa05652-04e7-4a42-9fd6-8dbc1c8b98fe

@parismiguel жаль это слышать :(. У вас есть привязкаRedirects с 4.0.0.0 на 4.1.1.0 в вашем приложении?

<dependentAssembly> 
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" /> 
</dependentAssembly> 

Мы изучаем, как сделать историю bindingRedirects более плавной: https://github.com/dotnet/corefx/issues/9846#issuecomment -287941109

ОБНОВЛЕНИЕ: глядя на вашу ошибку, кажется, что проблема в том, что ваша версия 4.1.1.0 не была найдена. Можете ли вы проверить каталог своего приложения, действительно ли существует нужная версия сборки?

@karelz, это было быстро, большое спасибо! Я видел материал bindingRedirects в предыдущих сообщениях, но я не уверен, где его разместить ... Я пробовал внутри своего .csproj, но у меня есть ошибки (прикрепленные как .txt). Относительно версии 4.1.1.0 I ' м не уверен, что последую ... Разве я не должен обновлять его до 4.3.1?

IbmVcaCore.csproj.txt

Связывание перенаправлений входит в ваш файл app.config или web.config:

Смотрите это для деталей:
https://msdn.microsoft.com/en-us/library/7wd6ex19 (v = vs.110) .aspx

Привет, @davidsh , спасибо за помощь!
В моем проекте нет ни одного из этих файлов ... это сборка проекта NET Core с использованием шаблона Visul Studio 2017 ... что мне не хватает?

Re: 4.3.1 vs. 4.1.1 - 4.3.1 - это версия пакета NuGet, 4.1.1.0 - версия сборки (ildasm / ILSpy / VS покажет ее вам).
Версии NuGet и сборки немного сбивают с толку, и сложно определить, какая из них принадлежит. Это в моем списке вещей, на которые стоит обратить внимание, если мы сможем соединить точки через документацию (например, на странице NuGet).

Если вы используете .NET Core, вам не нужны bindingRedirects, и, более того, эта проблема вас вообще НЕ затрагивает. Эта проблема характерна для настольных компьютеров (= .NET Framework).
Пакет NuGet 4.3.1 изменил только свою сборку рабочего стола, но не сборку .NET Core.

Если проблема не исчезнет, ​​сообщите об ошибке и отметьте меня там. Эта проблема доводится до сведения довольно многих людей (поскольку она имела большое значение), ваша проблема не связана с ней (по крайней мере, так выглядит), поэтому давайте будем добры ко всем уведомлениям / почтовым ящикам GH.

Всем : я создал новый выпуск dotnet / corefx # 17522, чтобы отслеживать обещанные мною вскрытия.
К сожалению, я пока не добился большого прогресса в этом направлении :( ... но, по крайней мере, каждый заинтересованный может начать следить за этой проблемой и избегать потенциального шума по этой проблеме (пытаясь помочь людям сосредоточиться на том, что им интересно).

@karelz, спасибо, я буду следовать вашим инструкциям и опубликую в вашем новом трекере проблем. С уважением.

@parismiguel не относится к новому выпуску, который я создал, пожалуйста, создайте новый. Тот, который я создал (# 17522), предназначен для вскрытия вскрытия, почему эта проблема (# 11100) так долго решалась.

спасибо @karelz и мои искренние извинения за то, что

Мне показалось, что я столкнулся с этим во время идеального шторма.

Я использую предварительную версию функций Azure с комбинацией Azure Key Vault (2.0.6) и Octopus Client (4.15.3).

Я пробовал перейти с System.Net.Http на 4.3.2 но при попытке использовать Key Vault все равно не получается.

Какие-нибудь советы?

@karelz

Не могли бы вы убедиться, что сборка из пакета Nuget 4.3.2 действительно используется во время выполнения? (исправлено в 4.3.1)