Runtime: Reglas de seguridad de herencia violadas por tipo: 'System.Net.Http.WebRequestHandler'. Los tipos derivados deben coincidir con la accesibilidad de seguridad del tipo base o ser menos accesibles.

Hoy vi esto desde otro informe. / cc @ChadNedzlek

Esto parece deberse a la falta de atributos de seguridad en System.Net.Http.dll fuera de banda en comparación con la bandeja de entrada System.Net.Http.dll. La versión de la bandeja de entrada tiene AllowPartiallyTrustedCallers. También lo hace la bandeja de entrada System.Net.Http.WebRequest.dll. Esto significa que todo se trata como SecurityTransparent a menos que se indique lo contrario.

A la OOB System.Net.Http.dll le falta AllowPartiallyTrustedCallers, lo que hace que todo sea crítico para la seguridad. Ahora, cuando la bandeja de entrada WebRequest.dll carga OOB System.Net.Http.dll, viola la regla de seguridad, ya que WebReqeuestHandler es transparente, pero HttpClientHandler del que deriva es crítico.

Mi repro:

1. Archivo> nueva aplicación de escritorio
2. Propiedades del proyecto> firma> habilitar la firma de nombre seguro
3. Agregar referencia a System.Net.Http.WebRequest
4. Instale System.Net.Http 4.1.0.
5. En la principal, simplemente llame a new WebRequestHandler ();

ericstj tiene razón, tengo el mismo problema aquí. Este es un problema crítico en System.Net.Http 4.1.0 que debe repararse. No puedo usar esta biblioteca con .net4.6.1 porque carece de consistencia.

Este problema es un problema importante con el que lidiar y, en particular, hace que el uso del cliente de Azure KeyVault sea doloroso para mi equipo. La única alternativa indolora es cambiar a .NET 4.5.2, que no es aceptable.

Además, la solución alternativa enumerada anteriormente es insuficiente. Si desea utilizar NET 4.6.x, lo que hemos encontrado es que debe hacer lo siguiente para que funcione de manera confiable: deshabilite la verificación de dependencias, degrade System.Net.Http, edite el CSPROJ y deshabilite la redirección de enlace automático, modifique app.config, y normalmente limpiar / salir de VS / y reconstruir como he visto a menudo System.Net.Http en uso, incluso para proyectos triviales. Este es el procedimiento que soluciona esto de manera confiable.

1. Haga clic con el botón derecho en el proyecto en Visual Studio y seleccione Administrar paquetes NuGet.
2. Vaya a la pestaña Instalado.
3. Desplácese hacia abajo hasta SYSTEM.Net.Http, no Microsoft.Net.Http.
4. En el panel de la derecha, si Instalado no es 4.0.0.0, establezca Versión en 4.0.0.0.
5. En el panel de la derecha, establezca Comportamiento de dependencia en Ignorar dependencias. Si NO hace esto, el paquete Microsoft.IdentityModel.Clients.ActiveDirectory se degradará sustancialmente, lo cual NO es correcto.
6. Haga clic en Actualizar: este botón realmente debería estar etiquetado como "Cambiar a versión".
7. En la ventana Vista previa, verifique que el ÚNICO cambio enumerado sea "Instalar System.Net.Http". Si olvidó establecer el comportamiento de dependencia correctamente, el cambio adicional se enumerará aquí.
8. Haga clic en Aceptar / Sí / Acepto en los cuadros de diálogo de confirmación y espere a que se complete el procesamiento. Cuando esté completo, la lista de paquetes mostrará dos números de versión: la marca de verificación está al lado de la que está en uso.
9. En la pestaña NuGet instalado, seleccione la lista de Microsoft.IdentityModel.Clients.ActiveDirectory.
10. En el panel de detalles de la derecha, configure el comportamiento de dependencia en "Ignorar". Si no hace esto, cualquier adición posterior de NuGet fallará cuando se ejecute la validación de NuGet para este paquete.
11. En Visual Studio, seleccione Archivo | Guardar todo.
12. Abra el archivo CSPROJ para este proyecto en un editor de texto.
13. En / Project / PropertyGroup * 1 (el primer elemento PropertyGroup de Project), agregue la siguiente línea o cambie el valor de este elemento si ya existe:
    <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>
14. Guarde el archivo y vuelva a cargar el proyecto en Visual Studio.
15. Abra el archivo app.config para este proyecto.
16. Busque la línea para System.Net.Http y edítela para redirigirla a 4.0.0.0 en lugar de 4.1.0.0. Entonces encuentra esto:

<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> 

Y cámbielo a esto:

<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. Reconstruye el proyecto. Si obtiene una excepción al ejecutar el código de Azure Key Vault, uno o más archivos * .config en el bin / debug o directorios similares no se han actualizado. Puede que tenga que salir de Visual Studio para borrarlos y reconstruirlos.

dluxfordhpf, gracias por su tiempo explicando cómo ha resuelto esto. Redirigir a System.Net.Http 4.0 funcionó para mí en .net4.6.1, pero aún es muy difícil de mantener (la dependencia nuget). Esperando la versión que solucionará este problema.

La redirección podría causar problemas si la gente está usando alguna de las nuevas API agregadas en System.Net.Http 4.1.0.

en particular, hace que el uso del cliente de Azure KeyVault sea doloroso para mi equipo

@ChadNedzlek tuvo el mismo problema y pudo solucionarlo pasando un HttpClient que él mismo creó al constructor KeyVaultClient. Si no usa WebRequestHandler, evitará el problema.

P.EJ:

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 Creo que necesitas volver a poner AllowPartiallyTrustedCallers en System.Net.Http.dll. / cc @morganbr

@dluxfordhpf Muchas gracias por los pasos.
Es temporal y esperamos que se solucione pronto, pero aún así, ¡puedo seguir trabajando en el proyecto!

@terrajobst Este es un problema de bloqueo de producción. ¿Alguna idea de cuándo podemos arreglar NuGet? ¡Gracias!

Me encontré con esto yo mismo. Sería increíble si no descendiéramos al infierno de la dependencia en .Net. Va en esa dirección.

EDITAR: Se corrigió con una sugerencia de comentarios previos para usar el sistema httpclient ??
new KeyVaultClient(GetAccessToken, new HttpClient(new HttpClientHandler()))
Eso pareció conseguirlo ...

El problema solo empeora a medida que más y más paquetes nuget de Microsoft dependen de la última versión de System.Net.Http. Probablemente no soy el único que actualiza constantemente sus paquetes nuget de Microsoft a la última versión preliminar. Por ejemplo, paquetes que ya no me funcionan en su última versión:

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

Sigo sin entender por qué este paquete todavía está disponible. @terrajobst @coolcsh ¿podemos quitar / arreglar este paquete? REALMENTE está causando problemas con entornos de aplicaciones complejos. Perdí varias horas tratando de evitar que el paquete infractor se infiltrara en la construcción. ¡Gracias!

Estamos buscando enlazar a System.Net.Http en NET Framework en lugar de esta cosa rota de NuGet. Estoy de acuerdo, este problema es ridículo y muy costoso de tratar, ya que debe sincronizar las versiones de NuGet entre proyectos, evitar las actualizaciones de enlace automático y corregir / verificar su app.config. Lo que me sorprende es que está en un montaje tan utilizado. ¿Quizás a MS realmente no le importa tanto KeyVault?

También es utilizado por ActiveDirectory Nugget

He revertido algunas bibliotecas de apuntar a .NET Standard debido a esto y problemas relacionados donde los paquetes NuGet rotos simplemente estropean las aplicaciones que apuntan a .NET Standard. Este es un lamentable estado de cosas.

Gracias por archivar. Estamos investigando esto activamente. Manténganse al tanto.

Esto se ha convertido en un tema importante para mí; usamos muchos de nuestros propios paquetes nuget internamente. Y parece que Nuget simplemente _no_ dejará a esos bindingRedirect s solos. Cada vez que actualizamos uno de nuestros paquetes internos, cambia el redireccionamiento a newVersion="4.1.0.0" . ¿Hay alguna forma de evitar que haga eso, o hay una solución en el horizonte?

Se encontró al ejecutar la aplicación a través de HTTPS, que funcionó bien a través de HTTP. No estoy seguro de si existen otras diferencias significativas.
La solución alternativa de configurar newversion="4.0.0.0" funcionó para mí.

Sigue siendo un problema en NETStandard 1.6.1. ¡¿Por qué?!

System.Net.Http 4.3.0 está fuera. ¿Alguien lo intentó?

@LoulG Sí, me temo que sigue siendo un problema.

Hablé con @terrajobst en Twitter y me dijo que en realidad es un problema mayor y que ahora tienen como 10 personas trabajando en ello. Personalmente, no estoy seguro de por qué no están extrayendo las versiones de este paquete que muestran el problema, ya que pensé que para eso era la administración de paquetes. Pero lo siguiente que podemos hacer en este momento es esperar.

@LoulG lo mismo aquí, he actualizado todos mis paquetes Nuget, con el lanzamiento de .net core 1.1 y tengo este problema

System.TypeLoadException: reglas de seguridad de herencia violadas por tipo: 'System.Net.Http.WebRequestHandler'. Los tipos derivados deben coincidir con la accesibilidad de seguridad del tipo base o ser menos accesibles.

En primer lugar, creo que se debió a IdentityServer / IdentityServer3.AccessTokenValidation pero, al leer este problema, entiendo mi situación t_t, pasé varias horas para tratar de resolverlo

EDITAR:
DIOS MIO,
La solución alternativa de configurar newversion = "4.0.0.0" también funcionó para mí

Intento actualizar a 4.3 pero, el mismo problema: (((

mismo problema aquí después de la actualización

El problema sigue presente con 4.3.0.

@terrajobst ¿ puede proporcionar alguna actualización sobre este tema o alguna información adicional sobre el problema más profundo al que hace referencia

¿Alguna razón por la que esta corrección funciona localmente, pero cuando se implementa en un servicio en la nube de Azure, el error persiste?

A veces, empaquetar Azure puede arruinar sus redireccionamientos vinculantes, intente descomprimir el cspkg y vea lo que realmente se está implementando.

Aquí está la versión de System.Net.Http.dll

He estado trabajando en esto durante unos días. Estaba muy feliz de encontrar esta solución y lloraba cuando lo implementaba en Azure.

¿Qué pasa con el archivo .config que contiene redireccionamientos vinculantes para el proyecto? De hecho, espero que aún implemente la versión rota del ensamblado debido a que CopyLocal es verdadero desde el paquete nuget, pero la redirección de enlace debería garantizar que la versión de marco del ensamblado se cargue dentro de la VM del servicio en la nube.

¡¡¡Es!!! ¿POR QUÉ?

<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>

Mirando hacia atrás en mi proyecto, el web.config también se ha revertido. Tendré que recoger esto de nuevo por la mañana. ¡Gracias por algunas pistas!

Encuentro que si usa AutoGenerateBindingRedirects y luego modifica cualquier paquete nuget para el proyecto, "arreglará" sus redireccionamientos previamente modificados a mano a la versión rota. Muy frustrante.

Pero parte del problema es que si NO usa AutoGenerateBindingRedirects cuando agrega nuevos paquetes, es posible que también tenga otros problemas.

He estado lidiando con esta tontería durante más de una semana mientras tenía que implementar una nueva versión de nuestra aplicación. Lo mejor que puedo sugerir es que adquiera el hábito de verificar su web.config cada vez que implemente.

Sí, debe deshabilitar las actualizaciones de enlace mediante la edición manual en CSPROJ, y luego corregir las redirecciones de enlace .config Y reconfigurar NuGet en la GUI para NO actualizar las dependencias, y ENTONCES está bien. Sí, este es un PITA importante, me sorprende que haya estado en producción tanto tiempo. Mi equipo ha estado maldiciendo regularmente durante meses.

Desafortunadamente, seguir lo anterior solo corrige mi entorno de desarrollo y no azure prod. Verifiqué el último archivo pub y el web.config se configuró correctamente junto con mi dll que se publicó siendo la versión que se muestra arriba. Desafortunadamente, mis problemas están relacionados con la biblioteca de Azure Search, por lo que esta solución resultó ser prometedora. ¿Alguna otra idea por ahí? Con un poco de pérdida. Gracias por la ayuda.

¿Por qué tiene más de 2 meses? Este es un gran problema. Por favor, arregla.

Este es completamente un problema de interrupción del envío, es absolutamente necesario abordarlo.

Por el amor de Dios, chicos, arreglen esto ya. Esto es idiotez.

@suprduprmn Actualicé y consolidé todos los paquetes y luego cambié esto en todos los archivos app.config y web.config:

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

Solo entonces mi aplicación web se iniciaría en Azure y podría realizar llamadas https a los servicios de Azure que dependen de System.Net.Http. YMMV pero buena suerte.

Y @terrajobst ... ¿hay un lugar adecuado en el que pueda quejarme formalmente por descuidar problemas importantes como este? Las reglas despreocupadas del código abierto no se aplican aquí. Esto es Microsoft Showstopper 101 de 1995. No hay forma de que "la comunidad" pueda ayudar. Tienes que arreglarlo y tienes que diseñar herramientas y procesos para asegurarte de que deje de suceder. Veo cosas como esta en varios proyectos de Microsoft y es totalmente inaceptable. Es obvio que existen grandes lagunas en las pruebas. Los escenarios básicos simplemente no se instalan o construyen de forma limpia y mucho menos funcionan correctamente en tiempo de ejecución.

Quiero disculparme por el tiempo que nos llevó XXXL responder a este problema. Ha pasado 1 mes desde la última respuesta y el problema está abierto por más de 3 meses. Estoy de acuerdo en que esto no es aceptable para un tema de alto impacto como este.

Me llamaron la atención esta mañana y traté de hacer algunas excavaciones históricas durante las últimas horas. La buena noticia es que las personas adecuadas están investigando el problema durante las últimas semanas (tal vez incluso más, no revisé todo el historial). Lamentablemente, la solución es muy complicada :( y por eso todavía no tenemos una buena respuesta o ETA (aunque no es una excusa para la falta de actualización por nuestra parte).
Hay un par de posibles soluciones, pero incluso los expertos aún no están de acuerdo y cada una de ellas tiene sus desventajas.
Comenzaremos sincronizaciones diarias sobre el problema la próxima semana, tratando de encontrar una solución al problema lo más rápido posible. Publicaré actualizaciones (con suerte con más detalles técnicos) cuando las tengamos, al menos semanalmente.

Lamentablemente, esto es lo mejor que puedo hacer en este momento (es decir, una disculpa sincera y la seguridad de que lo trataremos con seriedad y haremos todo lo posible para solucionarlo lo antes posible). Si alguien tiene sugerencias alternativas, soy todo oídos.

@karelz No quisiera distraer al equipo de solucionar el problema en este momento, pero personalmente me encantaría escuchar un análisis post-mortem sobre la causa raíz de este problema y cómo logró el control de calidad. Esto ha causado grandes quebraderos de cabeza y creo que la transparencia ganaría algo de confianza.

@jahmai Entendido, también me interesa eso, pero primero quiero centrarme en la solución. Luego, podemos analizar qué sucedió, por qué y cómo prevenir tales percances en el futuro.

Gracias por la respuesta. Creo que la mejor solución en este momento es desactivar cualquier paquete que no apunte a System.Net.Http 4.0.0. Hay al menos 2 versiones del paquete que son malas. ¿No es ese el punto de distribuir estas cosas a través de NuGet en primer lugar?

abrazos @ ms-team

Además, para que lo sepas, entre este problema, los problemas relacionados con HttpClient que están tan mal diseñados, los problemas relacionados con Microsoft.Security.Owin.Jwt que se rompen con las dependencias actuales y el estado de .NET Core ...

Es un momento increíblemente frustrante para ser desarrollador de .NET en este momento. Cada implementación ahora requiere 30 minutos de verificación de referencias de enlace de ensamblado para que mis aplicaciones no se rompan en producción. Este no es el Microsoft que he defendido durante tanto tiempo. Los amo chicos, y no quiero ser duro en absoluto ... Pero siento que se necesita un poco de amor duro para restaurar el status quo de calidad.

Lo que sea que deba hacerse. Incluso si eso significa enviar un 4.3.1 que hace referencia al antiguo paquete 4.0. Por favor, hágalo pronto.

Gracias chicos. FWIW, si necesita hacer un cambio importante, hágalo. No nos gusta esto, pero hemos vivido con el dolor durante varios meses, y ahora que sabemos que está comprometido, podemos esperar un par más, incluso si tenemos que hacer algunos cambios en la API.

Algo está fuera de lugar aquí. Llevo 15 años enviando aplicaciones C #. Irónicamente, a medida que Microsoft envía abstracciones de nivel superior, paso cada vez más tiempo profundizando en aspectos internos de los que nunca antes tuve que preocuparme. LO ESTÁS HACIENDO MAL.

No soy lo suficientemente inteligente como para entender por qué revertir las marcas de confianza en esta biblioteca es un gran problema, ni tampoco entiendo por qué no tengo más control sobre eso desde mi aplicación de todos modos.

Si quisiera sorprenderme en tiempo de ejecución por errores aleatorios inducidos por la administración de paquetes y bibliotecas que el compilador no detectó, escribiría mis aplicaciones en Ruby.

Actualización rápida:
Nos hemos reunido varias veces esta semana. Hicimos una lluvia de ideas sobre las opciones y calculamos la financiación.
@CIPop está trabajando en este tema como máxima prioridad (el trabajo pasó de @davidsh, que será

Estado:

• Hemos sido capaces de reproducir @onovotny 's pequeña repro repro y artesanía originales.
• Estamos buscando la solución [3] a continuación, enfocando su pregunta pendiente restante, es decir, validando la viabilidad técnica de la opción.
• Estamos explorando en paralelo la solución [2] a continuación: explorando su pregunta abierta, es decir, evaluando el impacto de la solución en el ecosistema.

Descripción del problema

• Enviamos System.Net.Http 4.3.0.0 "OOB" en junio
  
  
  
  • Contenido notable (para este contexto): HttpCient, HttpClientHandler
  
  
  • Valor para el cliente: compatibilidad con certificados, compatibilidad con http2, pila WinHttp en el escritorio
  
  
  • Todas las plataformas, excepto Desktop, funcionan bien: para Desktop, la superficie API no tiene SecurityAttributes para el código PartialTrust (APTCA = AllowPartialTrustCodeAttribute)
  
  
  • En el escritorio, la biblioteca OOB anula el uso de System.Net.Http 4.0.0.0, que es parte de la plataforma (y tiene APTCA)
  
  
• System.Net.WebRequestHandler 4.0.0.0 es parte de Desktop
  
  
  
  • Depende de System.Net.Http y tiene APTCA, por lo tanto requiere que System.Net.Http tenga APTCA
  
  
  • Utiliza tipos internos de System.Net.Http (que tiene InternalsVisibleTo)
  
  
  • Es un tipo heredado "aburrido" que no queremos en .NET Core
  
  
• Hay bibliotecas (más de 3 paquetes NuGet y la aplicación ASP.NET Core en el escritorio) que traerán (indirectamente) tanto OOB System.Net.Http 4.3.0.0 como referencia a System.Net.WebRequestHandler 4.0.0.0. El combo evita que la aplicación se ejecute.

Soluciones

1. [NO ACEPTABLE] Redireccionamiento de enlace manual: manualmente por degradación de la aplicación (mediante redireccionamientos de enlace) System.Net.Http 4.3.0.0 a 4.0.0.0: es difícil entender qué / dónde y es un paso manual por aplicación
   
   
   
   • Nota: se utiliza hoy como "solución alternativa"
   
   
2. [CANDIDATO] Deshacer la decisión OOB - reenviar 4.3.1.0 como redireccionamiento a la bandeja de entrada Escritorio 4.0.0.0.
   
   
   
   • Desventaja: romperemos a los clientes que dependen de las nuevas funcionalidades
   
   
   • Pregunta abierta: ¿WCF u otras bibliotecas de NuGet en el escritorio se verán afectadas?
   
   
3. [CANDIDATO] Rociar atributos de seguridad en System.Net.Http
   
   
   
   • Hágalo solo para escritorio (use #if), no lo propague a otros paquetes (compile con la referencia de escritorio), agregue pruebas que lo hagan cumplir para el futuro.
   
   
   • Desventaja: algunas propiedades de WebRequestHandler específicas para la implementación de escritorio de System.Net.Http no funcionarán (por diseño, ya que cambiamos la implementación)
   
   
   • Nota técnica: los métodos asincrónicos deben ser SecurityTransparent (limitación del compilador de Roslyn), por lo tanto, no pueden llamar a (SecurityCritical) PInvokes; para cada llamada de PInvoke de este tipo, debe haber un método de envoltura SecuritySafeCritical (algo feo, pero sencillo)
   
   
   • Pregunta abierta: ¿Podemos hacer que las dependencias internas de WebRequestHandler funcionen con el nuevo System.Net.Http basado en WinHttp?
   
   
4. [RECHAZADO] OOB WebRequestHandler solo en el escritorio
   
   
   
   • Desventaja: empuja el problema hacia arriba (algunos ensamblajes APTCA dependen de ello)
   
   
   • Desventaja: algunas propiedades de WebRequestHandler específicas para la implementación de escritorio de System.Net.Http no funcionarán (por diseño) - ver [3] arriba
   
   
   • Desventaja: todos tienen que agregar la dependencia o decirle a NuGet que instale la última
   
   
5. [CANDIDATO] Agrupe System.Net.WebRequestHandler.dll en el paquete System.Net.Http NuGet
   
   
   
   • 2 desventajas iguales a las de [4] arriba:
     
     
     
     
     
     1. Desventaja: empuja el problema hacia arriba (algunos ensamblajes APTCA dependen de ello)
     
     
     
     2. Desventaja: algunas propiedades de WebRequestHandler específicas para la implementación de escritorio de System.Net.Http no funcionarán (por diseño) - ver [3] arriba
     
     
     
   
   

Gracias por la información detallada, lo apreciamos.

¿Qué tal una combinación de la Opción 2 y el reenvío de 4.3 como 5.0? Dado que técnicamente fue un cambio importante, también podría enviar un OOB WebRequestHandler.dll para escritorio como v5.0. Eso le permitiría volver a implementar la funcionalidad en WinHttp, desaprobar las propiedades que no se asignan y les daría a todos un camino a seguir en la forma en que SemVer se supone que debe permitirle. Upstream también necesitaría corregir su código, pero eso no es inesperado en una versión importante, y también podrían limitar sus paquetes para no incluir 5.0.

Quiero decir, tengo la idea de querer enviar todos los grupos de paquetes de marco con los mismos números de versión, pero a) ese perro ya estaba jodido cuando ustedes enviaron todo como 4.0 en lugar de seguir las versiones de escritorio existentes, yb) el actual el control de versiones del ensamblaje ya está por todas partes (el paquete System.Security.Claims 4.3 incluye 4.0.2 dll, lo cual es muy molesto cuando se tiene que crear redireccionamientos vinculantes). Entonces el daño ya está hecho.

dotnet / corefx # 3 me parece la única solución de causa raíz real.

@robertmclaws No creemos que el cambio de versión
Es aún peor que el efecto de "ruptura" saldrá a la luz solo cuando combine varias cosas. Es por eso que este problema se deslizó en primer lugar: no tenemos pruebas para ese combo (y yo diría que está bien, no se pueden probar todas las combinaciones, pero podemos discutirlo en la autopsia más adelante).

Tampoco creo que a nadie le importen demasiado las versiones de grupos de marcos completos. Honestamente, si creyera que ayudaría a la mayoría de los clientes, votaría simplemente por cambiar los números, simplemente no creo que ayudaría casi en absoluto. Simplemente cambiaría nuestro mensaje a "sí, estás roto, eso es lo que dice la versión, simplemente no te diste cuenta de qué tipo de cosas aceptas cuando tomas la versión", que es una excusa tonta en mi opinión.

Dada la diferencia de opiniones, me interesa lo que piensen los demás: utilice upvotes / downvotes en esta publicación:

• 👍 si está de acuerdo conmigo, es decir, si cree que enviar el cambio rotundo como 5.0 no hará una diferencia y la mayoría de las personas aún estarán quebradas, confundidas e impactadas.
• 👎 si está de acuerdo con la propuesta de @robertmclaws , es decir, cree que enviar el cambio

Para el control de versiones de cambios importantes, creo que 5.0 es una buena idea, pero no lo siento tan fuertemente.

Todavía estoy muy confundido acerca de qué está causando este problema en la primera
sitio. Ustedes realmente están hablando por encima de mi cabeza.

Me importa mucho la coincidencia de los números de versión, pero si eso tiene
para ir para detener este problema, me ocuparé de él.

¿No leí un artículo hace unos meses sobre cómo la mayoría de los
¿La biblioteca System.Net.Http se estaba extinguiendo a favor de una reconstruida?

El 15 de diciembre de 2016 a las 15:18, "Karel Zikmund" [email protected] escribió:

@robertmclaws https://github.com/robertmclaws No creemos que el
el cambio de versión marcaría la diferencia. La mayoría de la gente (aplicación y biblioteca
propietarios) por lo general simplemente "presionan actualizar a la última" en sus paquetes,
no importa cuánto cambió la versión (menor frente a mayor). Entonces el rompimiento
el impacto será exactamente el mismo.
Es incluso peor que el efecto de "ruptura" saldrá a la luz sólo cuando
combinas varias cosas. Es por eso que este problema se deslizó en el
primer lugar: no tenemos pruebas para ese combo (y yo diría
está bien, no se pueden probar todas las combinaciones, pero podemos discutirlo en
post-mortem más tarde).

No creo que a nadie le importen demasiado las versiones de grupos de framework completos
ya sea. Honestamente, si creyera que ayudaría a la mayoría de los clientes,
votaría simplemente por cambiar los números, simplemente no creo que
ayudar casi en absoluto. Simplemente cambiaría nuestro mensaje a "sí, eres
roto: eso es lo que dice la versión, simplemente no te diste cuenta de qué tipo de
cosas que acepta al tomar la versión ", que es una excusa tonta en mi opinión.

Dada la diferencia de opiniones, me interesa lo que piensen los demás:
por favor use upvotes / downvotes en esta publicación:

• 👍 si está de acuerdo conmigo, es decir, si piensa enviar el cambio de última hora
  ya que 5.0 no marcará la diferencia y la mayoría de las personas aún estarán rotas,
  confundido e impactado.
• 👎 si está de acuerdo con @robertmclaws https://github.com/robertmclaws 's
  propuesta, es decir, cree que enviar el cambio radical como 5.0 ayudará
  las personas entienden desde el principio que deberían mantenerse alejadas del paquete,
  porque romperá el combo con otra biblioteca y evitará
  dolor innecesario para los desarrolladores.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267446604 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAavtBRE24SlHsZHCYm5OhPbOGs6MfRzks5rIa68gaJpZM4JsdDX
.

Estoy de acuerdo. Obtuve algunos detalles del correo electrónico de hoy, pero todavía no estoy seguro. Sería bueno ver una buena descripción del problema interno para que comprendamos las soluciones propuestas.

@karelz Aprecio lo que intentas hacer aquí, pero realizar una encuesta sobre lo que significa "versión 5.0" es una pérdida total de tiempo para todos. Es GitHub la socialización, no la ingeniería. Enviaría una versión 5.0 HOY que soluciona esto y enviaría una 6.0 cuando descubra cómo configurar todas sus pequeñas anotaciones correctamente y / o refactorizar el código.

Declaraciones como "La mayoría de las personas (propietarios de aplicaciones y bibliotecas) generalmente solo presionan la actualización a la última" no son útiles. Así es como Perl 6, Python 3, Rails 3 y 4 y Node.js 1,2,3,4,5 y 6 lograron fragmentar las cosas. No sigamos esa pista.

@dluxfordhpf @ciel Desafortunadamente, esta es un área difícil de explicar. Todo proviene de Code Access Security "heredado" cuyo uso ya no se recomienda activamente.

Aquí hay un resumen de cuál es / fue su propósito:
https://msdn.microsoft.com/en-us/library/ee191569 (v = frente a 110) .aspx
https://msdn.microsoft.com/en-us/library/dd233102 (v = frente a 110) .aspx

El problema real tiene que ver con @karelz dijo con un tipo de un nivel de transparencia de seguridad (por estar en el marco de escritorio) tratando de derivar de un tipo que tiene una postura de seguridad menos restrictiva (porque los atributos faltan en el Versión OOB). Esto se debe a que CAS como concepto no existe en nada más que en .net de escritorio.

En el contexto de los documentos anteriores, consulte esta sección sobre reglas de herencia

Describe las reglas necesarias para la herencia de tipos en diferentes niveles de seguridad.

¡Gracias! Estoy familiarizado con CAS; los técnicos son maravillosos.

Dados todos los cambios de número de versión entre .NET Core, .NET Standard, et. Alabama. en el último año (y enviando un nuevo código con la versión 4.3 en NuGet que se ejecuta en 4.6.2, entiendo que Microsoft podría pensar que los números de versión no importan. Pero como alguien que administra por sí solo una arquitectura de aplicación muy compleja y distribuye más de 20 OSS NuGet paquetes, estoy totalmente en desacuerdo.

Pulsar "Actualizar todo" sin comprobar la compatibilidad es la forma más fácil en .NET de estropear tu aplicación y no saberlo hasta el tiempo de ejecución. La adherencia a SemVer es la única forma de mantener la cordura. Incrementar la versión principal comunica que algo se va a romper. Cuando señala ese cambio, obtiene la libertad de hacer lo que quiera para solucionarlo.

La solución propuesta me suena bien, pero solo me gustaría comentar sobre la matriz de prueba: el uso de HttpClient en el escritorio .NET será algo importante en el futuro previsible. Este combo realmente debería ponerse a prueba, aunque es cierto que no todas las posibilidades pueden / deberían probarse.

Sí, la prueba también me suena a evasión. Agregue los 100 paquetes principales a su proyecto de prueba unitaria y asegúrese de que su basura aún se ejecute. Parece el tipo de ingeniería básica que Microsoft solía hacer antes de darse cuenta de que podían despedir a los probadores y dejar que "la comunidad" resolviera estas cosas. Es una pérdida de tiempo tan terrible y frustrante.

Porque el "antiguo" control de calidad que nos trajo Windows ME y Vista era superior.

Además, estoy seguro de que insultarlos hará el trabajo más rápido.

El 16 de diciembre de 2016 a las 7:46 a. M., "Chadwackerman" [email protected] escribió:

Sí, la prueba también me suena a evasión. Suma los 100 primeros
paquetes a su proyecto de prueba unitaria y asegúrese de que su basura aún se ejecute.
Parece el tipo de ingeniería básica que Microsoft solía hacer antes
dándose cuenta de que podían despedir a los evaluadores y dejar que "la comunidad" solucionara esto
en lugar de eso. Es una pérdida de tiempo tan terrible y frustrante.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267597137 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAavtAUL3pmMiSRnFBe7DEa0y5AaZoVXks5rIpZIgaJpZM4JsdDX
.

Encontré al líder del equipo que nadie invita a las fiestas navideñas porque él
trata a la gente como una mierda.

El 16 de diciembre de 2016 a las 8:26 a. M., "Chadwackerman" [email protected] escribió:

Gritar tonterías, créanlo o no, hace el trabajo más rápido.
De lo contrario, tiene gerentes de desarrollo millonarios que no han escrito una línea de
código en 10 años diciendo "Vaya, esto de Github es genial. Vamos a piratear
emoji upvote / downvote y realice una encuesta para que no tenga que tomar una decisión ".
Como si eso fuera a resolver algo después de meses-hombre de trabajo y seis
horas de reuniones de triaje internamente. Es una falsa señalización social y
francamente, el tipo de ingenieros de BS que solían llamar la atención que nos brindaba calidad
como el cohete Saturno V. Y .NET, que fue el mejor paquete de idiomas
y biblioteca estándar de cualquier cosa en este espacio mucho antes de todo esto en línea
comenzó la idiotez.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267604666 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAavtEigDK5EqlA4LQVlxB_lfamMgHanks5rIp9-gaJpZM4JsdDX
.

O tal vez encontró al tipo que aprendió a desbloquear a todo su equipo haciendo que Microsoft finalmente actuara sobre un problema que fue ignorado durante meses.

Microsoft tiene listas de errores y prioridades completamente duplicadas internamente. Github es un montón de tonterías sociales. De todos modos, no aceptarían una solicitud de extracción para este problema, por lo que esto se convierte en un hilo de atención al cliente. Los desarrolladores hicieron un mal trabajo aquí y está bien que lo escuchen.

Hay una gran diferencia en que los desarrolladores escuchen eso y sean un
gilipollas insufrible. Si los comentarios insultantes es la única forma en que puede transmitir una
punto, entonces tal vez debería limitarse a reprender a las personas que al menos
pagando para aguantarte.

El 16 de diciembre de 2016 a las 8:34 a. M., "Chadwackerman" [email protected] escribió:

O tal vez encontraste al tipo que aprendió a desbloquear a todo su equipo
lograr que Microsoft finalmente actúe sobre un problema que se ignoró durante meses.

Microsoft tiene listas de errores y prioridades completamente duplicadas internamente.
Github es un montón de tonterías sociales. No aceptarían una solicitud de extracción para
este problema de todos modos, por lo que se convierte en un hilo de soporte al cliente. Los desarrolladores
hizo un mal trabajo aquí y está bien que lo escuchen.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267606461 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAavtHTdxym7pvR9KRomyIT14FVaILLFks5rIqF8gaJpZM4JsdDX
.

Responderé solo porque Microsoft usa "ordenar por GitHub number_of_comments" para ayudar en lo que @karelz filtró tan cortésmente como "averiguar la financiación". También puedes usar la escala de emoji de GitHub para validar tus valores sociales.

Dude entró y dijo que SemVer no importa. Es nuestro deber como ingenieros señalar lo absurdo que es eso. Es un caso clásico en el que necesitamos un gerente más senior que tenga experiencia real, o un tipo más joven que realmente sepa cómo impactan las cosas en el mundo real. Los mandos intermedios que juegan a alcaldes en GitHub son el verdadero problema aquí. Ahora siéntase libre de hacer clic en el pulgar hacia abajo para que todos podamos seguir con nuestro día, gracias.

Sí, este error ha apestado, y me sorprende ver que se ha publicado una ruta principal sev1. Pero en mi humilde opinión, el verdadero dolor de esto se debe al diseño de NuGet: cualquier paquete de NuGet que utilice un proyecto debe ser referenciado manualmente por todos los consumidores de ese proyecto. Eso es una duplicación innecesaria y un mal diseño, lo prepara para el fracaso. El asistente de sincronización es inútil cuando el diseño básico es malo. NUGET es la razón por la que este error es tan doloroso. De lo contrario, echaríamos humo, pondríamos la desagradable solución en Util y podríamos olvidarnos de ella. Pero ahora tenemos que tener cuidado en los 18 proyectos que consumen más o menos, que crecen cada mes. ESE es la razón por la que este error es tan doloroso: debido a NuGet, la solución no se puede aislar en un proyecto, debe tocar todo y seguir haciéndolo.

Además, me hago eco del sentimiento de que lo importante es Desktop / Windows .NET. Me alegra saber que Microsoft .NET llegará a Linux, pero el dinero está en Windows, ahí es donde deberíamos tener la mejor experiencia, y quiero que funcione mejor.

Una queja constante que tiene mi equipo es "¿por qué tenemos que descargar todos estos paquetes?" Creamos una consola o un proyecto ASP.NET y todo lo que necesita está en la caja. Creas algo más moderno y 5 mil millones de descargas.

OK, me estoy alejando un poco. Gracias por su tiempo y atención, por favor avíseme si podemos ayudarlo a probar / evaluar / verificar documentos en busca de errores tipográficos / cualquier cosa que necesite, estamos dispuestos a ayudar.

La razón por la que este problema (y dotnet / runtime # 17786) nos ha causado tanto dolor es porque trasladamos nuestros servicios en la nube de los roles web de Azure a los servicios de Service Fabric y tuvimos que pasar a netcore / netstandard, pero aún ejecutándonos en el marco completo. aplicaciones.

Al principio hice la solución de redireccionamiento vinculante que pareció funcionar durante un tiempo, pero nuestros desarrolladores constantemente rompían algo al revertir accidentalmente un app.config, actualizar un paquete nuget y luchar contra AutoGenerateBindingRedirects (que deshabilitarlo era su propia pesadilla).

Finalmente, resolví esto forzando el uso de HttpClientHandler en todas partes. Eso implicó cambiar nuestro propio código, plantear problemas en bibliotecas de terceros e incluso usar trucos como la reflexión y la duplicación del código de terceros para solucionar el problema.

Entonces, sea cual sea la solución, si el nuevo paquete no es compatible con el HttpClient / HttpClientHandler más nuevo, no lo aceptaremos. Eso no es un gran problema porque en este momento las cosas están funcionando. Sin embargo, la "solución real" debe llegar poco después, ya que no quiero que se me bloquee la actualización de más paquetes de terceros que podrían estar moviendo su código a netstandard e introduciendo este problema.

@dluxfordhpf ... Sería bueno ver una buena descripción del problema interno para que comprendamos las soluciones propuestas ...

Intenté describir el problema aquí: https://github.com/dotnet/corefx/issues/11100#issuecomment -267394198.
En pocas palabras:

• El paquete Http NuGet 4.1 / 4.3 "anula" Http 4.0 en .NET Framework, pero no tiene atributos de seguridad. Además, utiliza diferentes componentes del sistema operativo bajo el capó (es decir, "gran cambio" + casos de esquina potencialmente rotos (aunque no es directamente relevante para este problema, es una señal de que hay problemas)).
• WebRequestHandler es solo una parte de .NET Framework, pero depende de Http 4.0 y requiere atributos de seguridad en Http.
• Una vez que toma la dependencia en Http 4.1 / 4.3 de NuGet y redirige la versión de .NET Framework de la bandeja de entrada 4.0, no puede usar WebRequestHandler.
• Para empeorar las cosas, Http tiene algunas API nuevas que forman parte de .NET Standard 1.6 y algunos componentes dependen de ellas. Por lo tanto, no podemos simplemente volver a la versión anterior.
• Y, por supuesto, los detalles lo hacen aún más complicado.
• Afirmar lo obvio: no existe una "solución correcta". Es cuestión de elegir el que tenga menos impacto en general.

@chadwackerman ... hacer una encuesta sobre lo que significa "versión 5.0" es una pérdida total del tiempo de todos. Es GitHub la socialización, no la ingeniería.

No es socializar. Si miras los votos, muestra que no hay una opinión unánime al respecto. Entonces, incluso si no confía en la opinión del equipo de CoreFX (con más de 10 años de experiencia con clientes de .NET) que dice "la gente no presta atención a la versión principal como deseamos ", espero que ayude ver que incluso algunos MVP ( @onovotny) comparte esa opinión. Mientras que otros MVP no están de acuerdo (@robertmclaws).

@chadwackerman ...

Es la opción [2] que expuse anteriormente (con diferentes números de versión). Es algo que estamos explorando en paralelo. Dado el impacto de la solución, no está claro " sí, obviamente eso es lo correcto, vamos a por ello ".

@robertmclaws ... Microsoft podría pensar que los números de versión no importan ... Cuando lo que quieras para solucionarlo ...

No intenté decir que no creemos en el control de versiones correcto. Simplemente creemos que a una gran parte de los desarrolladores no les importa y quieren que todo sea totalmente compatible siempre, es decir, no podemos hacer lo que queramos ni siquiera en las versiones principales. Eso se basa en los años de experiencia de nuestro equipo con el servicio .NET y el envío de paquetes NuGet.

@gulbanana ... Este combo realmente debería ponerse a prueba, aunque es cierto que no todas las posibilidades pueden / deberían probarse ...

De acuerdo, ahora que sabemos que es un combo importante, deberíamos agregarle cobertura. Y deberíamos hurgar un poco más en el área para ver si nos faltan otros combos similares alrededor del paquete Http NuGett.

@chadwackerman ... Agregue los 100 paquetes principales a su proyecto de prueba unitaria ...

Curiosamente, eso es similar a lo que propuse hace un año cuando enviamos un metapaquete incorrecto para UWP debido a la falta de la cobertura de prueba adecuada. No es tan fácil. Para detectar los errores interesantes (como este), también debe ejercitar el código. Muchas veces tienes que ejercitar el código de ambos combos en la misma prueba (no en este caso particular). En general, bastante difícil en la prueba infra.
Si tiene sugerencias e ideas que podríamos haber pasado por alto, háganoslo saber; vamos a crear un nuevo número para ese tema.

@chadwackerman ... y deje que "la comunidad" resuelva estas cosas en su lugar ...

Nosotros (puedo hablar en nombre de los equipos de CoreFX y CLR) NO estamos subcontratando las pruebas de productos a la comunidad a través de GitHub. Mantenemos un alto nivel en la calidad de lo que enviamos.

(tecla de acceso rápido accidental envió la respuesta antes de que la terminara ... continuará ...)

@chadwackerman ... Microsoft tiene listas de errores y prioridades completamente duplicadas internamente ...

No es cierto al menos en los equipos CoreFX y CoreCLR: GitHub es la base de datos de errores principal para todos los .NET Core. Otros productos que no son de código abierto (.NET Framework "completo" y .NET Native) utilizan principalmente bases de datos de errores internos.

@chadwackerman ... No aceptarían una solicitud de extracción para este problema de todos modos ...

No aceptaríamos una solicitud de extracción que no pueda abordar / explicar todas las inquietudes anteriores (incluidas aquellas con las que la persona que la envía no está de acuerdo personalmente). ¿Hay proyectos de código abierto que tomarían un truco rápido sin pensar en todo su impacto? Quizás si el 20% + de sus clientes están en el piso ... ese no es el caso aquí (todavía).

@chadwackerman ... Microsoft usa "ordenar por GitHub number_of_comments" para ayudar en lo que @karelz filtró tan cortésmente como "averiguar la financiación". ...

Primero, number_of_comments no es una métrica a la que prestamos atención (a menos que alguien "manualmente" se dé cuenta de que se sale del techo). Y definitivamente no tiene nada que ver con la "financiación".
Prestamos atención a cualquier cosa que tenga un impacto en los clientes, ya sea la cantidad de votos o la insatisfacción expresada por el cliente (en GitHub, Twitter, comentarios de publicaciones de blog, en cualquier otro lugar).
Este error entró en mi radar como "insatisfacción significativa del cliente" (otro empleado de MS en este hilo lo mencionó como tal internamente), por eso intervine.
Lo estamos financiando tanto como podemos en este momento. La única prioridad más alta sería un problema de seguridad o más del 20% de nuestros clientes está en el piso sin una solución alternativa.
Por cierto: Lanzar insultos no ayudará a acelerarlo ni a influir en la toma de decisiones.

@dluxfordhpf ... por favor, avíseme si podemos ayudarlo a probar / evaluar / verificar documentos en busca de errores tipográficos / lo que necesite, estamos dispuestos a ayudar ...

Gracias, agradecemos tu oferta. Definitivamente agradeceremos la ayuda cuando tengamos bits listos (y validados en los repros que tenemos), para validar más escenarios de un extremo a otro. Querremos evitar una situación en la que arreglemos solo algunos escenarios de un extremo a otro, mientras dejamos otros dañados de la misma manera o de otra manera.

@jahmai ... pero nuestros desarrolladores constantemente rompían algo al revertir accidentalmente un app.config, actualizar un paquete nuget y luchar contra AutoGenerateBindingRedirects (que deshabilitarlo era su propia pesadilla). ...

¡Gracias! Ese es un buen ejemplo para aclarar el impacto del problema en el trabajo diario de los desarrolladores que necesitamos escuchar y comprender. Nos ayuda a comprender que la combinación con las herramientas VS hace que trabajar con esta sea una verdadera pesadilla. Lo tendremos en cuenta al finalizar el plan de lanzamiento y las fechas (que comenzaré tan pronto como establezcamos la solución).

@jahmai ... si el nuevo paquete no es compatible con el HttpClient / HttpClientHandler más nuevo, no lo

Nuevamente, buenos comentarios para escuchar. Todavía estamos tratando de eliminar toda la historia de lanzamientos y correcciones de un extremo a otro, antes de que compremos por completo una solución. Lanzar un truco sin comprender el impacto en otros escenarios (como el suyo) sería un movimiento desesperado por nuestra parte; solo lo consideraríamos, si no sabemos cómo solucionarlo, o si la solución adecuada es extremadamente costosa. Aún no estamos allí.

Por favor, mantengamos la discusión técnica de ahora en adelante.

Actualización rápida:
Solución [3] " Rociar atributos de seguridad en System.Net.Http " como se describe arriba parece ser costoso (6w +), por lo que re-pivotamos sus detalles de implementación interna: Estamos considerando usar la implementación Http original de la versión 4.0 del paquete + implementar las 8 nuevas API en la parte superior lo mejor que podamos (algunas pueden estar técnicamente rompiendo con soluciones alternativas). La compatibilidad con http2 y otras "nuevas pilas de WinHttp" no estarán disponibles de forma predeterminada, quien quiera que las desee debe llamar a un constructor especial (técnicamente es un cambio importante, pero con suerte no mucha gente depende de las nuevas ventajas 4.1 / 4.3 bajo el capó) .
El costo parece ser significativamente menor hasta ahora, pero todavía estamos persiguiendo y costando 2 extremos perdidos (API), antes de que establezcamos el plan final. Tendremos que tomar algunas decisiones de compatibilidad "interesantes" al menos para 2 API, pero no deberían ralentizar el tiempo hasta el lanzamiento de la corrección.

Por cierto: Solución [2] " Deshacer decisión OOB " resulta tener más impacto de lo que supusimos originalmente (por ejemplo, rompería .NET Standard 1.6, creando más desorden y explicaciones a largo plazo). Lo mantendremos como opción de último recurso en este momento, si lo anterior resulta ser demasiado costoso o irrazonable.

Si actualmente está analizando los casos extremos en torno a este problema, podría valer la pena echarle un vistazo:
https://github.com/gulbanana/repro-netstandard-httpclient

esta solución demuestra que actualmente en vs2017rc, el uso de netfx y netstandard da como resultado versiones en conflicto de system.net.http. No estoy seguro de cómo se relaciona eso con lo de OOB.

Aprecio (y francamente admiro) la franqueza de @karelz aquí, pero voy a hacer sonar la bocina de versionado por última vez.

Si no confía en el equipo de CoreFX (con más de 10 años de experiencia con clientes de .NET), la opinión que dice "la gente no presta atención a la versión principal" ... basada en los años de experiencia de nuestro equipo con el servicio de .NET y el envío de NuGet paquetes ...

No estoy seguro de qué falacia lógica es esta, pero no se puede afirmar una comprensión profunda del control de versiones en equipo con muchos matices en medio de un problema de control de versiones masivo como este.

Con suerte, al menos podemos estar de acuerdo en que NO superar el número de versión principal y tener un cambio radical es lo peor de todos los mundos. Sin embargo, aquí estamos. Hablando de "presupuesto" y "más de 6 semanas de tiempo de desarrollo" ... para dar una palmada en algunos atributos. Para un sistema de confianza obsoleto que nunca funcionó realmente y que no uso. Debido a problemas desatendidos en el compilador.

Amazon Web Services envió soporte completo .NET Core para todos sus servicios el verano pasado. Su reciente actualización baja el listón de netstandard 1.5 a 1.3. Mientras tanto, el equipo de Azure ni siquiera puede hacer que los blobs funcionen.

Ustedes enviaron bits que rompen globalmente las solicitudes web https, en silencio durante las compilaciones y en voz alta en tiempo de ejecución, y aún no tienen un plan para resolverlo cuatro meses después. Dejaré esto por ahora porque obviamente estás trabajando en ello, pero si los problemas más importantes aquí no te mantienen despierto por la noche ...

Muchas gracias por su sinceridad y sus explicaciones.

@chadwackerman ... no se puede reclamar un conocimiento profundo y experimentado en equipo del control de versiones en medio de un problema de control de versiones masivo como este. ... Con suerte, al menos podemos estar de acuerdo en que NO superar el número de versión principal y tener un cambio radical es lo peor de todos los mundos. Sin embargo, aquí estamos. ...

Estás haciendo 2 grandes suposiciones:

1. Supuesto: El cambio de ruptura se conoce (también conocido como ruptura) antes del envío.
   
   
   
   • Ese no es el caso de este problema, como es común para la clase de "cambios importantes no intencionados". Sí, las cosas a veces se escapan :(. Las métricas importantes son IMO: reacción rápida (estoy de acuerdo en que no lo hicimos bien en este tema hasta ahora) y disminución / baja frecuencia de tales errores.
   
   
2. Supuesto: Los expertos en versiones son capaces de revisar todos los cambios (lo que no es así) y que la gente en general nunca comete errores (ciencia ficción).
   
   
   
   • En este caso particular, el plan de API System.Net.Http (las nuevas 8 API para escritorio) fue revisado de alto nivel antes del envío también por expertos en versiones. Proporcionaron sugerencias y orientación sobre opciones. Desafortunadamente, el nivel de ruptura no fue reconocido de antemano por nadie (ni expertos del área ni expertos en versiones), por lo que la solución elegida condujo a estos problemas.
   
   

También quiero señalar que al descartar nuestra experiencia en el control de versiones, básicamente está diciendo " si usted (el equipo de .NET) alguna vez comete un gran error (este error), no puede llamarse experto incluso en el historial pasado y patrones (área relacionada) ".
Eso es un gran martillo en mi opinión y no es realista. Las personas / equipos cometen errores ocasionales (como este). Eso no los hace inadecuados para ser expertos en las áreas cercanas (o incluso en el área en particular). La clave es si pueden aprender de sus errores y hacerlo mejor en el futuro.

@chadwackerman ...

El costo no proviene de "atributos abofeteados", esa es la parte fácil. La parte costosa proviene de la pregunta abierta sobre la opción [3]:

https://github.com/dotnet/corefx/issues/11100#issuecomment -267394198: Pregunta abierta: ¿Podemos hacer que las dependencias internas de WebRequestHandler funcionen con el nuevo System.Net.Http basado en WinHttp?

Resulta que eso es bastante trabajo, las dependencias internas son demasiado desagradables :(

Realmente aprecio toda la discusión sobre esto. Seriamente. Es impresionante. Gracias por estar abierto a esto.

Sin embargo, al final del día, aquí está el problema dotnet / corefx # 1: ustedes reescribieron una gran parte de la pila. La parte que es fundamental para casi todo. Y no tiene una cobertura de prueba ni remotamente adecuada. No debería haber necesitado expertos. Debería haber tenido un caso de prueba claramente documentado que se escribió en el momento en que se escribió WebRequestHandler (o se tomó la decisión de no migrar a Core), y debería haberse roto cuando empezaron a jugar con él.

Después de más de 5 años de enviar material relacionado con .NET 4.0, realmente no hay excusa para no tener cobertura de prueba de integración EN ALGÚN LUGAR que hubiera detectado esto. Si se encuentra poniendo una excusa para ello, no está exigiendo la excelencia de su equipo.

Si hubiera habido:

• cobertura de prueba adecuada
• un proceso de control de calidad adecuado
• una versión beta adecuada
• y una forma adecuada de enviar problemas a equipos específicos responsables de paquetes específicos

... esto no hubiera sucedido.

Si el equipo:

• no había estado tan empeñado en hervir el océano al reescribir TODOS LOS ASPECTOS ÚNICOS de .NET al mismo tiempo
• prestó atención a las advertencias de aquellos de nosotros que hemos hablado sobre esto desde que comenzó el proyecto ".NET 5 / MVC 6"

... esto no hubiera sucedido.

Es una combinación de fallas que rompieron .NET en general, en una escala que no recuerdo haber sucedido antes. Pero también ha roto una gran parte del ecosistema y cada vez es más difícil de arreglar.

Esto tiene un costo _muy real_ y _ significativo_. Tuvimos que apagar nuestro servidor CI hace semanas e implementarlo manualmente, verificando el web.config manualmente cada vez. Desplegamos al menos una vez al día. Cientos de dólares a la semana en horas-hombre adicionales, sin mencionar las demoras por tener que dedicar ese tiempo a otra cosa.

Nuevamente, esto ni siquiera tiene en cuenta las innumerables horas que se ocupan de las fallas existentes en la arquitectura HttpClient: eso no es eliminar las instancias correctamente, mantener abiertas las conexiones TCP y almacenar en caché las entradas de DNS durante demasiado tiempo.

Entonces, vas a recibir críticas por esto. Y merecidamente.

Y en función de lo "cara" que sea la solución, espero que esté poniendo un gran equipo de varias de sus mejores personas para solucionarla correctamente, y no ponerla sobre los hombros de una persona.

... Las palizas continuarán hasta que mejore la moral.

Deje que corrijan el error que admitieron y que no se amarren intactos.

Para que quede claro, no estoy tratando de vencer a un caballo muerto con mi última publicación. Pero últimamente he visto demasiadas excusas de Microsoft. "Nombrar es difícil". "El control de versiones es difícil". "La gente comete errores." Esta es la mentalidad de la debilidad y no de un equipo que lucha por la excelencia. Realmente admiro a @karelz por venir aquí y discutirlo. Pero cualquier empleado de MSFT debe dejar de justificar lo sucedido y dejar que la gente se desahogue sin sentir la necesidad de dedicar tiempo a corregir el registro. Esta no es una excepción de caso súper extremo cuando usa un DateTime o algo así. Es un desastre colosal debido a que más de una persona no exige la excelencia en su trabajo, y debe tratarse como tal. La única respuesta válida es: "Nos equivocamos. Rompimos .NET. No vamos a descansar hasta que se arregle". Porque esa habría sido la respuesta hace 5 años cuando Gu dirigía el programa.

Simpatizo con @karelz, quien recientemente asumió su cargo después de mucho tiempo trabajando en .NET. Y ciertamente no debería tener que defender a su equipo. No culpo a los trabajadores aquí; obviamente es un problema de gestión.

Pero tal vez no debería sorprendernos ver que la lógica circular y el tipo de doble lenguaje que está generalizado en ciertas capas de la administración de Microsoft no funcionan bien frente a los clientes del mundo real que realmente usan el material.

En .NET Core, Microsoft SQL Server perdió la capacidad de escribir valores sin firmar. Una vez más, un problema olvidado que está en la parte superior de los sitios de UserVoice desde 2014. Las empresas no pueden darse el lujo de cambiar el esquema de su base de datos (especialmente algo tan delicado como sin firmar) porque un par de administradores de programas no pueden estar en la misma página después de tres años. Mientras tanto, Redis y SQLite (lo que sea) funcionan bien, y Scott Hanselman hace demostraciones de ferias comerciales como si esto realmente funcionara. Definitivamente hay una brecha cada vez mayor entre las realidades internas y externas aquí y los problemas deben ser ventilados (cortésmente).

Nombrar ES difícil. El control de versiones ES difícil. Microsoft tiene una perspectiva única, en la que tratan con clientes de todo tipo de industrias, desde la vanguardia hasta la vid moribunda. Los conceptos para el enfoque de desarrollo que parecen "obvios" en los juegos son ajenos a los sistemas CRM. La forma en que aborda los problemas, lo que es importante y lo que no lo es, varía. Y luego agrega tecnología avanzada, diferentes enfoques a los problemas: DAO vs ADO.NET vs LINQ vs EF para usar una comparación fácil común. Finalmente, competencia en el ámbito de los servidores de Internet, modelos de hardware completamente nuevos con tabletas llave en mano y el virus Balmer. Formas completamente nuevas de pensar y modelar problemas con diferentes limitaciones y ventajas.

En un momento trabajé para una ... gran empresa famosa. Un grupo de productos lanzó un producto con un componente compartido actualizado que interpretó su pila de llamadas de manera diferente dependiendo de cómo se inicializó. Nunca lo probaron con nuestro producto e hizo que nuestro producto explotara todo el tiempo. Obvio, pero lo enviaron de todos modos. A esto lo llamamos el incidente del "fuego amigo".

Una vez me perdí un error en el que si lo instalamos en la unidad D, al desinstalarlo bajo ciertas condiciones, el producto podría ... eliminar todos los archivos del disco duro. Tuvimos que quemar 40.000 dólares en CD impresos.

La gente no es perfecta y cometemos errores. La culpa, sin embargo, es un concepto inútil. Nos hace sentir poderosos a través de conceptos destructivos como la vergüenza y la humillación. La humildad y el perdón son más poderosos. Así es como lo hacemos mejor, aprendemos mejores formas y, a veces, simplemente, por qué algo es importante en primer lugar.

Sí, el problema también me enoja, pero se está solucionando. Y sabes qué: problemas de código abierto como este languidecen durante décadas antes de que de todos modos se moleste en intentarlo. Simplemente intente Kerberos en un sistema Linux o busque en GSSAPI. InitializeSecurityContext / AcceptSecurityContext es mucho más fácil. El dinero importa.

En un momento trabajé para una ... gran empresa famosa. Un grupo de productos lanzó un producto con un componente compartido actualizado que interpretó su pila de llamadas de manera diferente dependiendo de cómo se inicializó. Nunca lo probaron con nuestro producto e hizo que nuestro producto explotara todo el tiempo. Obvio, pero lo enviaron de todos modos. A esto lo llamamos el incidente del "fuego amigo".

Esos eran dos productos diferentes. .NET es un solo producto. Y no intento culpar a nadie. Yo culpo al proceso. Parece que debido a que Microsoft se convirtió en OSS, tiraron por la ventana los procesos que los ayudaron a enviar el marco de desarrollo más estable de la historia. Siento que esto se habría detectado si se hubiera enviado en .NET 4.6.3 en lugar de en NuGet.

La torpe transición a OSS ciertamente no ayuda. No culpo a OSS, pero Microsoft ciertamente parece estar orgulloso de cometer todos los errores obvios.

Utilizo palabras como "calidad" para describir el software, pero ahora usan palabras como "compromiso". Ejecutar el compilador instrumentado que llama a casa veinte veces más al día porque tengo que editar manualmente los archivos .config no es un "compromiso adicional". Pero este es el mito de todo Internet en estos días.

Considere el equipo de BashOnWindows que decidió que un grupo de personas sin experiencia en Linux escribieran una corrección del modo de usuario de Linux en vivo en GitHub. El trabajo es un ejercicio de ingeniería básico pero tedioso para marcar las casillas y no hay absolutamente ninguna razón para involucrar comentarios de la comunidad para la priorización de funciones. Pero se fueron.

Seis meses después, "la comunidad" tuvo que decirles que no podía manejar archivos que terminan en un período. Esto no es ingeniería de software; es una especie de ejercicio de marketing extraño. Los gerentes que están implícitos en el esquema merecen retroalimentación. Y algunas de ellas pueden resultar desagradables de escuchar.

Editar para agregar: trato similar con la debacle de Bash. Envío de bits rotos en vivo, vínculos extraños con otros componentes (solo se puede instalar como parte de Windows Update) y, por supuesto, Scott Hanselman de alguna manera hace demostraciones en vivo a pesar de que no podía ejecutar tar y mucho menos un compilador.

Parte de la retórica aquí huele a "los buenos viejos tiempos" de Microsoft, lo cual es irónico porque todos los cambios que estamos presenciando ahora son una respuesta directa a la demanda de los clientes de que Microsoft evolucione.

Estábamos hartos del código cerrado y las reglas draconianas de ingeniería inversa (descompilación), así que obtuvimos fuentes de referencia y ahora código abierto.

Estábamos hartos de los errores de .net Framework que afectaban a todas las aplicaciones instaladas en una máquina y nos tomó mucho tiempo corregirlas y requirieron que los departamentos de TI y de distribución empresarial calificaran cada actualización de la versión de .net Framework antes de que pudiera suceder, por lo que ahora estamos avanzando hacia enviando paquetes nuget con nuestras aplicaciones para que podamos implementar la solución tan pronto como esté disponible.

Estábamos hartos de que Microsoft Connect cerrara todos los demás errores porque "funcionaba según lo diseñado" o nos tomaba 6 meses incluso programar un lanzamiento, por lo que ahora tenemos proyectos de Github administrados mucho más de cerca por el equipo que realmente escribe el código y todo el la comunidad puede dar fácilmente su 2c en cada elemento de trabajo de la comunidad.

Estábamos hartos de que Microsoft tomara todas las buenas ideas de la comunidad y creara un clon propietario que no funcionaba bien con herramientas que no eran de Microsoft, así que ahora podemos usar NPM, Gulp, NodeJS, etc.

Estábamos hartos de que C # solo fuera viable para Windows, y proyectos como Mono luchaban incluso por mantenerse a la par, mientras tenían que solucionar errores o falta de funcionalidad con #ifdef en todas partes, por lo que ahora tenemos a Xamarin impulsando el desarrollo de Mono con fuentes de referencia y permitiéndonos para codificar el lenguaje C # más reciente y compartir la misma base de código en .net, UWP, iOS, Android y netcore.

Todo esto está sucediendo a la vez porque lo ha hecho. No vamos a esperar a que Microsoft se ponga al día mientras ofrece piezas de funcionalidad estables y perfectas que solo resuelven la mitad de nuestros problemas en un momento dado.

Mi problema no es que todo este cambio esté sucediendo a la vez. Ni que aparezcan temas como este. El problema real para mí es que _ tomó meses para que este problema se reconociera como un problema importante _ y está tomando _ incluso más meses descubrir cómo solucionarlo _.

Tres semanas y sin actualización. Feliz Año Nuevo a todos.

Edite para agregar esta cita de @karelz ya que la subestimación parece desencadenar un grupo ligeramente diferente de copos de nieve especiales aquí:

Publicaré actualizaciones (con suerte con más detalles técnicos) cuando las tengamos, al menos semanalmente.

@chadwackerman en serio, ¿comprendes que tu mala actitud no ayudará a que este problema se solucione más rápido? Y aparte de eso, te estás burlando de ti mismo aquí. Mejora tu tono.

Que tono Hizo una declaración, que tiene la ventaja de ser precisa, y luego les deseó a todos un Feliz Año Nuevo. Si lo tomaste negativamente, ese es tu problema.

Y con respecto a esa primera declaración: este es un problema importante que no aparece hasta el tiempo de ejecución. Hace cinco años, ScottGu o Rob Howard habrían tenido un equipo en este 24-7 hasta que se envió una solución. Ahora es sólo "ya sabes, lo haremos".

¿Sabes qué hará feliz a la gente? Arreglar el problema. De lo contrario, hay algunos clientes cabreados y algunos de ellos están en este hilo. Tienen todo el derecho a estar enojados. Así que busca algo más que hacer con tu indignación, @pollax. No has contribuido con nada significativo a este hilo y nadie te ha ungido como Policía del pensamiento de GitHub. Tampoco ha desperdiciado> $ 5K del dinero de su empresa en este problema.

Ok, tal vez leí demasiado y por el tono que usó en comentarios anteriores, leí este último con un tono un poco irónico. Lo siento por eso.
Respecto al tema; Te escucho. A mí mismo me preocupa (de lo contrario, no estaría observando este problema tan de cerca), así que no haga suposiciones sobre lo que he / no he desperdiciado en términos de dinero / recursos en esto. Pero como desarrollador, sé que lo peor es tener a alguien mirándote cuando intentas solucionar un problema importante.

Estoy de acuerdo con su lectura del sarcasmo y estoy de acuerdo en que no es productivo. Sin embargo, también estoy de acuerdo con la sensación de "cuándo se va a arreglar". Desafortunadamente, este problema CAT1 de la ruta principal simplemente no prestó atención hasta que muchas personas se expresaron bastante al respecto. Espero que haya alguna mejora en el proceso internamente para resolver esto; Sería una mierda para todos si la única forma en que podemos obtener soluciones es a través de malas palabras.

También recibo un informe de esto sucediendo en el marco completo con nuestro paquete nuget Exceptionless. ¿Alguna solución sólida o solución alternativa?

También obtengo este ASP.NET Core de autohospedaje desde un servicio de Windows que ejecuta el marco completo 4.6.2. La dependencia NETStandard.Library 1.6.1 me obliga a usar System.Net.Http 4.3.0.

La dependencia NETStandard.Library 1.6.1 me obliga a usar System.Net.Http 4.3.0.

y este es mi mayor problema con toda esta situación

cada vez más paquetes dependen del metapaquete, lo que me obliga a actualizar cada dependencia que tengo (o pelear una batalla cuesta arriba para degradar / ignorar algunas específicas)

esto va en contra de la promesa anterior de "mezclar y combinar" de las dependencias del sistema

Tuve que degradar mi sistema a 4.5.2 desde 4.6.1 (y perdiendo mucho tiempo), porque cada segundo paquete traía .net 1.6 y su defectuoso System.Net.Http

Si estos fueran solo paquetes de terceros, bueno, que así sea, puedo evitarlos, molestar a los mantenedores para que usen dependencias más granulares, pero la mayoría de mis departamentos eran de MS, y espero que MS use dependencias granulares, no simplemente golpee .net 1.6 en el archivo nuget

Planeaba enviar una actualización durante los últimos días, así que aquí está:

El trabajo de @CIPop fue reemplazado por un problema de seguridad. Su trabajo fue recogido por @davidsh. @davidsh planea enviar PR a principios de esta semana (es decir, cualquier día de ahora).

Aquí hay detalles sobre nuestro plan de ejecución y estado:

Plan de alto nivel:
A. Reemplace WinHttpHandler con HttpClientHandler en net46 build de CoreFX
B. Implementar 8 nuevas API en HttpClientHandler que presentamos en el paquete 4.1.0.0 OOB

Plan de ejecución:

EDITAR 2017/1/12: el plan de ejecución se movió a la publicación más alta https://github.com/dotnet/corefx/issues/11100#issue -173058293

@niemyjski ¿ Alguna

Hay una solución para degradar el paquete ofensivo a 4.0.0.0 (consulte https://github.com/dotnet/corefx/issues/11100#issuecomment-246469893), desafortunadamente según los comentarios anteriores, cualquier edición de las dependencias de NuGet lo volverá a activar. - que es la razón clave por la que este problema es tan doloroso.

Espero que haya alguna mejora en el proceso internamente para resolver esto; Sería una mierda para todos si la única forma en que podemos obtener soluciones es a través de malas palabras.

Tengo algunas ideas (y preguntas) sobre las mejoras del proceso aquí, para evitar que problemas de impacto importantes en el futuro pasen desapercibidos durante tanto tiempo. Sin embargo, estoy aplazando intencionalmente esa discusión DESPUÉS de que hayamos enviado una solución.

Woot !!!

Bien hecho chicos @karelz

Gracias por la actualización. PlatformNotSupported sería mejor que nada, ya que son nuevas apis en las que el software heredado no depende.

Parece que después de la corrección, la unificación a través de redirecciones vinculantes seguirá siendo necesaria, pero una redirección al ensamblado más nuevo en lugar del anterior, ¿qué nuget puede generar correctamente?

Ahora que PR dotnet / corefx # 15036 está registrado, este problema debería desaparecer con net46. System.Net.Http.dll ahora usa la pila HTTP incorporada de .NET Framework. Esto significa que tiene una compatibilidad del 100% con WebRequestHandler.

Pruebe los paquetes más recientes en el feed de desarrollo de MyGet. Querrá utilizar los paquetes System.Net.Http.dll más recientes que, a partir de hoy, son:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

versión 4.4.0-beta-24913-02.

Puede usar paquetes de fuentes de desarrollo cambiando las fuentes de origen del paquete NuGet con herramientas de línea de comandos o Visual Studio.

Instrucciones:

Línea de comando:
Agregue lo siguiente en nuget.config, enelemento:

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

Estudio visual:
En VS, Tools-> Options-> Nuget Package Manager-> Package Sources -> Add, en Source, use esta url, https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

En cualquier caso, asegúrese de incluir la fuente de desarrollo de MyGet como la primera fuente de la lista.

Y para resumir la solución en dotnet / corefx # 15036, terminamos con un 100% de compatibilidad de aplicaciones con la superficie API original de .NET Framework System.Net.Http 4.0 y un 100% de compatibilidad de aplicaciones cuando usamos WebRequestHandler .

En términos del nivel de soporte para las propiedades más nuevas agregadas a HttpClientHandler (que son parte de .NET Core 1.1 y posteriores), lo siguiente resume el comportamiento esperado de estas propiedades más nuevas cuando se ejecutan en el destino 'net46' :

1) CheckCertificateRevocationList público bool
Lanza PlatformNotSupportedException

2) Public X509CertificateCollection ClientCertificates
Implementado

3) ICredentials público DefaultProxyCredentials
Implementado

4) público int MaxConnectionsPerServer
Implementado contra la lógica actual ServicePoint

5) public int MaxResponseHeadersLength
Implementado

6) IDiccionario públicoPropiedades
Implementado

7) función públicaServerCertificateCustomValidationCallback
Implementado, excepto que el primer parámetro siempre es nulo debido a la incapacidad actual para asignar HttpWebRequest internos a HttpRequestMessage

8) SslProtocols públicos SslProtocols
Lanzamientos PlatformNotSupportedException

¡Woo hoo! ¡Gracias chicos!

¿Alguien tuvo la oportunidad de validar los bits de @davidsh ? Realmente agradeceríamos una validación de extremo a extremo en los escenarios 7-ish que se insinuaron en este hilo.

Hemos podido validar la reproducción simplificada de @onovotny hasta ahora. Sería genial recibir un par de confirmaciones más sobre repros que no tenemos localmente. ¡Gracias!

Una vez que tengamos eso, avanzaremos hacia la migración del cambio a la rama 1.1 y lanzaremos un parche, con suerte la próxima semana.

Haré algunas pruebas esta semana. Acabo de entrar en una escalada, así que no puedo comenzar durante 1-2 días, supongo.

@dluxfordhpf ¡gracias! Aprecio tu ayuda.

Acabo de instalar 4.4.0-beta-24913-02 en mi proyecto. Parece ayudar a mi caso.

Caso: Autohospedaje de ASP.NET Core desde un servicio de Windows que ejecuta el marco completo 4.6.2. La dependencia NETStandard.Library 1.6.1 me obliga a usar System.Net.Http 4.3.0.

El feed myget es muy lento en mi experiencia. Tomó unos minutos instalar 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

¡Gracias @ annemartijn0 por la confirmación y por describir el escenario!

Actualmente, esta página tarda entre cinco y siete minutos en devolver un resultado:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

¿Por qué Microsoft subcontrata infraestructura vital a estas pequeñas empresas turbias y pequeños sitios estúpidos? ¿Realmente está eligiendo fijar su negocio Y el mío en una empresa en Bélgica llamada Tech Tomato?

De todos modos ... ya tenía un feed myget pero no estaba bajando esta biblioteca hasta que reinicié Visual Studio, hice clic en el botón "actualizar" enterrado en un cuadro de diálogo en alguna parte y luego reinicié Visual Studio por segunda vez. Actualmente estoy escribiendo esto mientras Visual Studio 2015 intenta restaurar mis paquetes.

Actualización: Visual Studio todavía se está agitando, pero finalmente apareció mi actualización de la página myget. Muestra quizás una docena de descargas al día de esta versión de la biblioteca. Mientras tanto, Visual Studio lo resume como "System.Net.Http - 75.8K descargas". Siempre asumí que estas estadísticas me decían algo incorrecto, pero aquí hay un gran ejemplo de por qué no es lo que quiero. Como mínimo, dígame el estado de la versión actual frente al resumen para no convertirme involuntariamente en un probador alfa sin optar explícitamente por la locura durante este momento absurdo en la historia de .NET.

5 horas después y todavía no puedo probar este parche:

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'

Cinco minutos después...

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 es un incendio de neumáticos.

Tranquilo, @chadwackerman . Has _optado_ a su feed beta / alfa / no de producción, por lo que significa que estás listo para solucionar problemas, etc. Dicho esto, he estado usando myget durante años (suscripción paga) y tengo muy pocos problemas con eso. Entonces, tal vez ... solo tal vez ... ¿podría ser su computadora / conexión de red / lo que sea? (He tenido grandes ganancias usando MyGet durante los últimos 12 meses).

.NET no es un incendio de neumáticos, en este momento. Claro, hay montones de queso moviéndose y muchas partes móviles y cosas que pueden (y lo hacen) salir mal. Pero hay un montón de gente que hace grandes cosas con los bits RC y RTM lanzados. Personalmente, he decidido usar solo material de lanzamiento público, ya ni siquiera BETA o RC. Así que mis expectativas son: menos problemas pero tengo que esperar más. Entonces, si algunas de estas cosas le resultan realmente frustrantes, tal vez espere un poco más para que parte de este trabajo de desarrollo alcance el estado RTM.

El trabajo del equipo de corefx (y los demás en el mundo .NET-core) ha sido excelente y una excelente bienvenida con respecto a pasar a github / open-and-transparent, en comparación con los bad-ole-Balmer-day's, así que vamos todos tratan de mantenerse positivos y útiles para los mantenedores de repositorios. Todos aquí son humanos y solo intentan hacer del mundo un lugar mejor: un byte a la vez.

@chadwackerman Parece que myget feed sufre en este momento. No estoy 100% seguro de cómo funciona myget, pero creo que si tiene un host dedicado ("dotnet.myget.org"), los feeds están realmente alquilados y tienen límites de calidad de servicio.

Ir aquí muestra que el paquete existe, pero tarda un poco en aparecer: https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

@PureKrome Soy un ex gerente de desarrollo de Microsoft a quien se le pidió que verificara esta compilación (ver arriba). Después de escalar personalmente este error internamente porque nadie en el equipo de .NET lo sabía. Y ahora no pueden enviarme un maldito binario.

Reconozco un incendio de llantas cuando veo uno. Solía ​​sacarlos para Microsoft para ganarme la vida.

@chadwackerman Puedo entender tu frustración con los problemas con el feed. Sin embargo, los insultos ('pequeños sitios estúpidos' y 'pequeñas empresas turbias') están fuera de lugar.
Tech Tomato está fundado / dirigido por personas calificadas: @maartenba , premio MVP de su antiguo empleador y @xavierdecoster , empleado actual de MS; en un país (al que soy partidario) que fomenta la innovación. El nombre de la empresa es poco relevante y que la empresa se fundó en Bélgica muestra que el equipo de .NET Core busca soluciones más allá de Redmond, WA.
Espero sus contribuciones constructivas para ayudar a resolver este problema.

Contenido editado por moderador

Se envió un informe del Código de conducta en contra de algunos de los comentarios en este hilo y, como resultado, hemos eliminado parte del material que se considera que ha violado ese código. Si tiene alguna pregunta o inquietud al respecto, envíe un correo electrónico a [email protected].

@chadwackerman, su anterior puesto en la empresa no le da derecho a golpear a nadie ni a insultar a nadie. Además, la gran mayoría de sus 'contribuciones' a este hilo no solo han sido poco constructivas, sino mezquinas, infantiles y fuera de tema. Troll en otro lugar.

Hola amigos, aquí Martin de la Fundación .NET quería explicar esto .

Aprecio plenamente que el problema original planteado por este hilo sea frustrante y que la gente quiera que se solucione. También comprendo algunas de las preocupaciones más amplias en torno a la calidad y la entrega y la fuerza de los sentimientos en general. El equipo está trabajando para resolver este problema, continuarán manteniendo a la gente actualizada.

Mientras tanto, mantenga el tono profesional y evite hacer comentarios que puedan ser percibidos como ataques personales contra otros. He sido deliberadamente liviano con las ediciones hechas, ya que quería preservar algo de la fuerza del sentimiento y no desinfectar demasiado las cosas, pero por favor mantén las cosas civilizadas.

¿Alguien más ha intentado ponerse en contacto con Tech Tomato? No hubo respuesta a mis consultas.

Así es como se ve si intenta hacer un trabajo real solucionando advertencias de compilación extrañas después de agregar el feed:

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

... y así.

Y este enlace todavía tarda más de 5 minutos en mostrar una página:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

El hecho de que esto sea a) aún no solucionado b) ignorado por la comunidad yc) tolerado por el equipo de .NET como parte del desarrollo diario sirve para reforzar las fallas obvias en el proceso, las herramientas, la cultura y la administración que llevaron a este error a para empezar, además de que el error en sí se ignoró durante meses hasta que yo personalmente lo escalé internamente.

Espero la autopsia que prometió @karelz .

Hola Chad,

Ese tiempo de carga de la página es algo que estamos viendo. El tiempo de restauración de NuGet no es normal. Si es posible, ¿puede comunicarse con nosotros (MyGet) a través del soporte en MyGet.org con una mención de su versión de NuGet.exe en uso, así como un seguimiento con el interruptor -Verbosity Detallado habilitado? Esto definitivamente nos ayudará a identificar cualquier problema de rendimiento.

¡Gracias!

Host de la consola del administrador de paquetes, versión 3.5.0.1996

Veré cómo obtener registros de la línea de comandos a medida que Visual Studio pasa de sólido como una roca a inestable una vez que agregue el feed myget.org. Y una vez que ocurre un error al tirar hacia abajo un paquete, todo se vuelca.

ps @karelz : fuego de neumáticos.

¿Puedes probar esta línea de comandos con el último (nocturno) NuGet.exe de www.nuget.org/downloads?

Comando exacto: NuGet.exe instala System.Net.Http -Version 4.4.0-beta-24913-02 -Verbosity detallada

Esto debería generar también todas las acciones de descarga intermedias. ¡Gracias!

@maartenba :

En el enlace que envió, "último" apunta a https://dist.nuget.org/win-x86-commandline/latest/nuget.exe. Esa es la versión que ya tengo, así que no creo que sea una noche.

Descargué el paquete nocturno NuGet.CommandLine.4.0.0-rtm-2254.nupkg, ejecuté la instalación de nuget.exe en él y fallé al intentar extraer archivos de myget.org. FYI: 1,5 segundos para devolver un 404 de dotnet.myget.org.

Si esta no es la forma correcta de instalar una compilación nocturna o un paquete local, infórmelo. Puede enviarme un correo electrónico a este nombre de usuario en gmail si prefiere desconectarlo.

Todavía estoy feliz de ayudar pero ... guau. Las cosas realmente deberían moverse en la dirección de la simplicidad, no yo solucionando problemas en el host del paquete secundario para el host del paquete primario usando una caída nocturna del administrador de paquetes que, a pesar de estar en la versión 4.0.0-rtm, de alguna manera tiene cinco métodos manuales distintos para actualizándose en su página de distribución, cada una de las cuales requiere la intervención manual del usuario.

ps @karelz ... oh, no importa. :)

Totalmente de acuerdo, pero los registros serían muy útiles para descubrir dónde se encuentra el cuello de botella (ya sea el host del paquete secundario, el cliente en sí, un nodo CDN loco, rayos cósmicos, ...). Nos pondremos en contacto contigo sin conexión para ver si podemos resolver esto. Realmente agradezco su ayuda en esto.

Me he dado cuenta de que myget.org es bastante lento, pero pude instalar el paquete en cuestión con éxito en un tiempo "razonable" (en una red Wi-Fi pública).

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.

Definitivamente deberíamos analizar la lentitud general de myget.org, pero probablemente fuera del alcance de este problema; después de todo, no es el escenario típico del cliente. @maartenba ¿cuál es el mejor lugar para discutir eso?
Aquí (sobre este tema en particular), centrémonos en cómo desbloquear la validación de un extremo a otro, por ejemplo, utilizando algunas soluciones creativas.
También me pregunto si otras personas han sido bloqueadas tan mal como @chadwackerman , o si la experiencia de @chadwackerman es extremadamente mala, en comparación con otros.

@chadwackerman dado que el objetivo principal aquí es validar el escenario de un extremo a otro, me pregunto si puede proporcionar los pasos del escenario. Alguien más aquí (que no esté tan bloqueado por el uso de myget.org como tú) podría finalizar la validación en tal caso. Eso debería reducir su dolor y perder el tiempo de su lado. Por supuesto, asumiendo que es factible y asequible por su parte.

La alternativa de último recurso, que me gustaría evitar, es omitir la validación de su escenario por completo; si obtenemos algunos otros escenarios de extremo a extremo validados, podríamos estar bien (asumiendo el peor de los casos donde @maartenba no podrá solucionar su mala experiencia en myget.org :().

@karelz, tomando esto sin conexión con Chad, informará aquí una vez que averigüemos qué está pasando.

Hechos de antecedentes:

• El feed de myget.org es utilizado por compilaciones diarias, CI, flujo de trabajo de desarrollo, etc. Por lo tanto, se critica mucho a diario. Ninguno de estos problemas de rendimiento se manifiesta en esos escenarios (cuando lo hicieron en el pasado, actuamos sobre ellos, porque afectaron el flujo de trabajo de nuestros desarrolladores; redujimos los tiempos de sincronización de 30 a 60 minutos a <5 minutos en los últimos meses). Tengo entendido que es raro que alguien en el equipo de .NET o en la comunidad use myget feed en VS, lo que IMO explica por qué el mal rendimiento pasó desapercibido en ese escenario.
• Este problema me lo remitió un compañero de trabajo en este hilo el 2016/12/9; por eso me uní a la discusión aquí. No tengo conocimiento de ninguna otra escalada interna. Dado que continuamente hago avanzar este problema internamente en varios equipos (casi a diario), creo que estoy al tanto de todos los eventos relacionados con este problema.

@karelz Sí,

Desde entonces verifiqué que MyGet.org se está portando mal con las máquinas de varios amigos en las costas este y oeste. La mía es una instalación limpia reciente de Visual Studio 2015, sin complementos, definitivamente sin ReSharper. Los comentarios de los usuarios y el manejo de errores en Visual Studio son deficientes. Incluso aquí, otros usuarios informan retrasos similares. Dejaré esto por ahora para liberar el hilo, pero no pretendamos que MyGet no está estropeado y que todo el sistema de empaquetado de NuGet (y la capacidad de NuGet para actualizarse) no huele levemente a goma quemada y no factor que contribuye a este error. Ambos originalmente como parte de la causa raíz e incluso hoy como parte del intento de probar y enviar la solución.

No estoy seguro de si deberíamos seguir discutiendo esto en este hilo o abrir otro hilo para ello. De todos modos: informe de estado!

Estamos en contacto con @chadwackerman por correo electrónico. ¡Gracias Chad por el registro que envió!

En cuanto a la "lentitud", el perfil preliminar nos dice que esto se debe al número de versiones del paquete y al impacto de ese hecho en el tamaño de descarga de los datos del protocolo. Por ejemplo, algunos paquetes requieren 4 MB de datos JSON para descargarse y analizarse para recopilar metadatos. Esto provoca un gran aumento en el uso de la memoria en el cliente NuGet y la necesidad de analizar una gran cantidad de datos JSON; definitivamente hay margen de mejora allí, aunque los nightlies 4.0.0 del cliente parecen comportarse mejor.

En el lado de MyGet, implementaremos la paginación para estos blobs de protocolo para reducir el tamaño de descarga en el protocolo. Puede que tarde una semana en publicarse. También perfilaremos tanto el servidor como el cliente en estas solicitudes y veremos si hay espacio para la optimización en ambos lados.

También estamos buscando acelerar el tiempo de carga de la página (pero eso es secundario, tener un trabajo de instalación / restauración rápido es una prioridad).

Después de horas de experimentación, pude actualizar a System.Net.Http 4.4.0-beta-24913-01 sin fallar Visual Studio. Luego intenté actualizar de 24913-01 a 24913-02 y obtuve un error adecuado en lugar de un bloqueo.

Es 2017 y actualizar la compilación nocturna del componente HTTP central para todo el sistema desde la "compilación del lunes" hasta la "compilación del martes" toma más de cinco minutos de tiempo de reloj de pared en un i7 de 8 núcleos y requiere más de 4 GB de RAM.

El proyecto en cuestión es un trabajo web (una aplicación de línea de comandos renombrada) que consta de 27 líneas de código.

Curiosamente, @karelz afirma que esto funciona muy bien para todo el equipo de .NET y que no tiene ningún problema para absorber el binario, incluso mientras toma un café con leche del Starbucks local.

Pude instalar el paquete en cuestión con éxito en un tiempo "razonable" (en una red Wi-Fi pública).
https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.4.0-beta-24913-02 971ms

Aquí hay algunos hechos alternativos:

Intentando recopilar información de dependencia para el paquete 'System.Net.Http.4.4.0-beta-24913-02' con respecto al proyecto 'webjob', apuntando a '.NETFramework, Version = v4.6.1'
La recopilación de información sobre la dependencia tomó 4.22 min
Intentando resolver dependencias para el paquete 'System.Net.Http.4.4.0-beta-24913-02' con DependencyBehavior 'Lowest'
Resolución de acciones para instalar el paquete 'System.Net.Http.4.4.0-beta-24913-02'
Acciones resueltas para instalar el paquete 'System.Net.Http.4.4.0-beta-24913-02'
System.OutOfMemoryException: se lanzó una excepción de tipo 'System.OutOfMemoryException'.
en Newtonsoft.Json.Linq.JContainer.ReadContentFrom (JsonReader r)
en Newtonsoft.Json.Linq.JContainer.ReadTokenFrom (lector de JsonReader)
en Newtonsoft.Json.Linq.JObject.Load (lector de JsonReader)
en NuGet.Protocol.HttpSource. <> c.b__15_0 (flujo de flujo)

¿Pueden mover este problema MyGet / NuGet a un nuevo número? No tiene relación con el problema original.

@onovotny : podría considerar volver a abrir su problema a. Este problema ahora es muy largo, por lo que se ha reducido la usabilidad del problema.

@richlander en lugar de vigilar el hilo, ¿intentaría instalar la solución e informar si resuelve su problema específico? Todo el mundo parece estar bloqueado por este importante problema, pero la gente prefiere jugar al ping pong de GitHub que hacer el trabajo real para probar la solución.

Pruebe los ~ 7 escenarios de extremo a extremo informados por la comunidad (solicite ayuda a la comunidad, proporcione los pasos para consumir paquetes maestros en myget)

¿Cuáles son los 7 escenarios? ¿Todos pueden ayudar?

@richlander Me encantaría volver a abrir un problema, ¿solo me estás buscando para clonar este con las actualizaciones de @karelz ? No estoy seguro de cuál es la pregunta.

Mi caso de uso estaba trabajando con la API de Azure Storage, que funcionó por última vez en 4.0.1-rc2-24027. Parece que esto está funcionando ahora. Solo hice una prueba rápida, ya que me tomó unos 20 minutos actualizar todos los paquetes en mis proyectos desde MyGet.

@onovotny No lo

Verifiqué que el nuevo binario funciona de manera compatible en una aplicación local. No es de extrañar. Luego intenté cortar y pegar esas dependencias en mi proyecto de trabajo web y no pude hacer que funcionara en Azure. Webjob se carga bien pero falla cuando se activa, no se puede cargar System.Net.Http. Obviamente, esto es culpa mía y conozco el ejercicio para solucionarlo. Pero estoy prácticamente de vuelta a donde estaba cuando se abrió este error por primera vez: retocar las reasignaciones de enlaces y cuando toco NuGet se desata el infierno, pierdo una enorme cantidad de tiempo y mi proyecto pasa todas las pruebas localmente pero se rompe en tiempo de ejecución al implementar .

Entonces nuestros escenarios son:

1. Un paquete dependiente (Raven.Database) usa WebRequestHandler, que se estaba rompiendo en tiempo de ejecución como se informa en este problema.
2. Nuestro código usa el nuevo tipo y propiedades HttpClientHandler.

Anteriormente probé las correcciones de redireccionamiento vinculantes, pero eso condujo a conflictos, luego terminé usando hacks (inyección de reflexión, duplicación y modificación de código de terceros) para solucionar los problemas.

Actualicé a la versión beta y eliminé todo el código de pirateo, ¡y todo (nuestra aplicación, de un extremo a otro, desde el navegador hasta la base de datos) parece estar funcionando localmente! Todavía no he probado el código en la plataforma Azure, así que lo confirmaré una vez que esté hecho, pero considero este progreso significativo.

Además, al actualizar los paquetes, encontré tolerable usar la Consola del Administrador de paquetes de Visual Studio y usar este comando para actualizar los paquetes (en lugar de agregar otra configuración de alimentación y luego usar la interfaz de usuario, que es increíblemente doloroso):

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

Esto tomó 6 minutos 53 segundos para actualizar 20 proyectos.

Tenga en cuenta que todos nuestros proyectos tuvieron la siguiente redirección de enlace generada automáticamente, no tuve que jugar con las redirecciones de enlace en absoluto:

    <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>

¡Casi es hora de chocar los cinco!

@jahmai Cuando usé esa línea de comando, no actualicé mi referencia de 4.0 a 4.2 ni agregué las banderas de copia necesarias. Asegúrese de que estén configurados para System.Net.Http y las dependencias y debería funcionar bien en Azure.

Nuestro escenario es una dependencia directa de los tipos en System.Net.Http.
Probé Update-Package System.Net.Http -Version 4.4.0-beta-24913-02 -Source https://dotnet.myget.org/F/dotnet-core en un proyecto y hasta ahora parece funcionar bien. Eso es muy buena noticia.
Actualización Se olvidó de mencionar que las redirecciones vinculantes de 4.0.0.0 a 4.2.0.0 se aplicaron automáticamente.

Con respecto a los problemas de Nuget / MyGet, obtuve el siguiente resultado para este proyecto único:

La recopilación de información de dependencia tomó 37,47 segundos
La ejecución de acciones nuget tomó 35.15 segundos
Tiempo Transcurrido: 00: 01: 14.7537429

Tenga en cuenta que estoy en la zona horaria UTC +01: 00, no sé cuándo MyGet recibe más tráfico.

@pollax Gracias. Encontramos el problema (ver mi último comentario arriba): combinación de cliente + servidor. Trabajando para mejorarlo.

Puedo confirmar que el uso de la biblioteca beta System.Net.Http de MyGet funcionó para mi escenario:

• Aplicación de consola .NET 4.6 con dependencia de una biblioteca que usa System.Net.Http

El paquete nuget tardó alrededor de 90 segundos en descargarse de MyGet y el bindingRedirect en el app.config se aplicó correctamente.

Me complace ayudar a probar más escenarios si se han descrito en alguna parte.

Efecto secundario interesante: agregar la versión 4.4.0-beta de una biblioteca .NET solo para Windows rompió la implementación de una aplicación .NET Core en Linux.

"dotnet restore" está codificado en tiempos de recuperación de paquetes de 60 segundos. Y no hay una bandera para seleccionar solo una plataforma específica como admite "dotnet publish". Entonces, para una biblioteca multiplataforma, su pequeño nodo trabajador de Linux descarga un montón de archivos binarios de Windows innecesariamente, luego se agota y falla cuando llega a MyGet. Curiosamente, el problema de falta de memoria que bloquea Visual Studio en una máquina de 32 GB no afecta a un trabajador de Linux de 0,75 GB porque en su lugar cambia a la muerte.

Sí, lo registré en otro lugar. Y sí, se relaciona con este error incluso si aún no lo ve.

¡Gracias a todos por ayudarnos a verificar los escenarios! Hasta ahora, obtuvimos 5 confirmaciones: vea la lista detallada con enlaces en la publicación más alta. Considero que es una validación lo suficientemente buena como para pasar a las siguientes etapas.

• [4.a.ii] Todavía estoy persiguiendo el análisis de NuGet.
• [5.a] Le pediré a @davidsh que prepare las relaciones públicas contra la rama de lanzamiento / 1.1.0.

• [5.b] Estoy preparando el proceso para su lanzamiento (necesitamos la aprobación del nivel de director, pero dado el impacto en los clientes, no espero ningún rechazo).

• Estoy preparando información oficial sobre el lanzamiento del parche, con una lista de todos los cambios técnicos y soluciones alternativas (gracias a @davidsh por los datos).

Si alguien descubre alguna inquietud mientras tanto (relacionada con este problema específico), por favor dígalo lo antes posible. Dedos cruzados.

@onovotny : parece que el problema está avanzando, así que continuemos con este problema. Es genial ver que la gente está progresando positivamente.

@karelz Puede marcar mis escenarios que incluyen la línea de comandos 4.6 (Azure webjob) con dependencia de ServiceBus y una aplicación 4.6 con dependencias en Azure Batch. También una tercera aplicación con dependencias en AWS y Dropbox que moví previamente a .NET Core solo para evitar este problema (saqué una versión anterior para probarla hoy).

Problema de restauración de dotnet revivido en https://github.com/NuGet/Home/issues/2534 , Colaborador Covenant reparó el canal trasero, neumáticos pateados en https://github.com/Azure/azure-storage-net/issues/372 , MyGet registros enviados, registros de rendimiento adicionales solicitados en https://github.com/dotnet/cli/issues/5328 , y compré una enorme bolsa de palomitas de maíz para la discusión post-mortem.

¡Gracias @chadwackerman por su ayuda y confirmación! Disculpe los problemas que encontró en el camino.
He actualizado la publicación más importante.

De mi lista anterior:

Estoy preparando información oficial sobre el lanzamiento del parche, con una lista de todos los cambios técnicos y soluciones alternativas (gracias a @davidsh por los datos).

Agregué información a la publicación más importante; consulte la sección "Impacto del cambio - Cambios importantes" para ver la lista de cambios técnicos importantes (4), cada uno con una solución alternativa.

Bibliotecas de NuGet afectadas por el cambio técnico de última generación (descrito en la publicación más importante): afortunadamente, "solo" 4 bibliotecas de NuGet que utilizan cualquiera de estas nuevas API:

System.Private.ServiceModel_4.3.0

• https://www.nuget.org/packages/System.Private.ServiceModel/
• Autor: dotnetframework
• Descargas: 11K (última versión) / 800K (total)
• Descripción: Paquete de implementación interna no destinado al consumo directo. No haga referencia directamente. Proporciona implementación de paquetes System.ServiceModel.
• Notas:
• Estado: paquete no afectado : @zhenlan @mconnew del equipo WCF confirmó que usan las propiedades solo en compilaciones de .NET Core. En el escritorio, recurren a los archivos binarios de escritorio integrados.

Consul_0.7.2.1

• https://www.nuget.org/packages/Consul/
• Nombre: Cónsul
• Autor: https://www.nuget.org/profiles/highlyunavailable
• Descargas: 500 (última versión) / 65K (total)
• Descripción: https://github.com/PlayFab/consuldotnet/blob/master/CHANGELOG.md
• Notas:
  
  
  
  • 2 usos: https://github.com/PlayFab/consuldotnet/search?utf8=%E2%9C%93&q=ServerCertificateCustomValidationCallback
  
  
  • Problema presentado en GitHub: https://github.com/PlayFab/consuldotnet/issues/79
  
  
  • Correo electrónico enviado al autor a través de nuget.org
  
  
• Estado: paquete no afectado (problema de GitHub https://github.com/PlayFab/consuldotnet/issues/79 cerrado)

Octopus.Client_4.6.1

• https://www.nuget.org/packages/Octopus.Client/
• Autor:
  
  
  
  • https://www.nuget.org/profiles/paulstovell
  
  
  • https://www.nuget.org/profiles/OctopusDeploy
  
  
• Descargas: 250 (última versión) / 55K (total)
• Descripción: Ninguno
• Notas:
  
  
  
  • Problema archivado en GitHub: https://github.com/OctopusDeploy/OctopusClients/issues/121
  
  
  • Correo electrónico enviado al alias de soporte: [email protected]
  
  
  • Correo electrónico enviado a los autores a través de nugget.org
  
  
• Estado: paquete no afectado (detalles en el problema de GitHub https://github.com/OctopusDeploy/OctopusClients/issues/121)

Geotab.Checkmate.ObjectModel_5.7.1701

• https://www.nuget.org/packages/Geotab.Checkmate.ObjectModel/
• Nombre: Geotab SDK
• Autor: https://www.nuget.org/profiles/neilcawse
• Descargas: 150 (última versión) / 10K (total)
• Descripción:
  
  
  
  • Biblioteca SDK para acceder a las bases de datos de clientes de MyGeotab
  
  
  • Vea una lista completa de cambios en https://my.geotab.com/sdk/default.html#/whatsNew
  
  
• Notas:
  
  
  
  • Correo electrónico enviado al autor (director ejecutivo de geotab.com) a través de nugget.org
  
  
• Estado: propietario contactado, esperando respuesta

Disculpe las molestias a todos los autores de paquetes afectados.

En el bloqueo / intercambio de Visual Studio / NuGet en Linux: la razón de esto está en la forma en que funciona el protocolo NuGet. He documentado los hallazgos en este problema: https://github.com/NuGet/Home/issues/4448

En el lado de MyGet, implementaremos un cambio después del fin de semana (actualmente en prueba, ETA en producción el lunes 7 de febrero) que alivia este lado del servidor.

Fix en el lado de MyGet está activo. Debería funcionar bien en Visual Studio. Cuando use NuGet.exe, asegúrese de usar NuGet.exe incrustado en https://dotnet.myget.org/F/nuget-build/api/v2/package/NuGet.CommandLine (4.0 cada noche) - el 3.5 parece fallar al descubrir las dependencias (pero no siempre). Error registrado: https://github.com/NuGet/Home/issues/4512

Gracias por la inmersión profunda en este @maartenba. ¡Nunca subestime el impacto que puede tener incluso una pequeña reparación de herramientas!

Es interesante que todo el equipo de .NET se pierda tanto el bloqueo de Visual Studio como el problema de NuGet.

Una vez le pedí a una sala de más de 80 desarrolladores de Microsoft que levantaran la mano si alguien tenía problemas para establecer puntos de interrupción en el depurador. Tengo dos manos. El compilador cambió el formato de símbolo, no se podía construir el proyecto sin el último compilador, pero los depuradores aún no se habían actualizado.

Durante meses nadie pudo establecer un límite. ¡En dos plataformas ni siquiera se podía obtener un seguimiento de la pila! Me llaman al laboratorio de compilación a la 1 de la madrugada porque soy la única persona que hay alrededor, obtengo una pantalla llena de ensamblaje para un procesador para el que nunca he visto documentos, obtengo un seguimiento y el depurador se bloquea en el depurador.

Cuando cambia el formato del proyecto mientras cambia el código que analiza el formato del proyecto mientras realiza una prueba interna de una nueva versión del administrador de paquetes que se conecta a la nueva versión de Visual Studio, resultados como este. Un mortal solo puede lidiar con tantos cambios a la vez y es por eso que los desarrolladores siguen tirando la pelota por todas partes. ¡Tanto nosotros como ellos!

Si alguien quiere un script de PowerShell simple para arreglar bindingRedirect en todas las aplicaciones.config, aquí está. Probablemente no sea la mejor solución, pero en este momento tengo un proyecto con muchos subproyectos de webjobs y es realmente frustrante cambiar manualmente todos los enlaces de archivos después de actualizar algún paquete.

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"`

Ejemplo de uso:
./scripts/FixAppConfig.ps1 -SourceDirectory "--project-path--" -Package "System.Net.Http" -OldVersion "0.0.0.0-4.3.0.0" -NewVersion "4.0.0.0"

¿Cuándo volverá a hacerse público? :)

Nuestro cambio entró en la rama de lanzamiento / 1.1.0 el martes - versión del paquete 4.3.1. Todos los paquetes de la rama se cambiaron a estable ayer (esfuerzo independiente, pero también nos ayuda :)).
@davidsh hará una prueba de cordura en myget feed (ETA: hoy), luego pediremos una última validación aquí por comunidad (ETA: hoy, EOD). Una vez que tengamos la validación final en esa compilación, enviaremos el paquete a NuGet. Mi expectativa es que tomará menos de una semana.

Tuvimos un retraso en el progreso y la comunicación, porque teníamos que convencer a la sala de embarcaciones de por qué esta es la mejor y única solución.
Además de eso, estamos preparando un plan (basado en los comentarios de la sala de envío) para dejar de enviar este paquete fuera de prohibición por completo en .NET Standard 2.0 y reenviar todas las funciones al marco de escritorio integrado (la funcionalidad de .NET Core no se modificará) - es decir, no se necesitarán redireccionamientos vinculantes si apunta a .NET Standard 2.0. Una vez que tenga detalles sobre el impacto en todos los escenarios, actualizaré este hilo (en 1-2 semanas).

Esa es una buena noticia y hará que netstandard2.0 sea más fácil de usar.

@davidsh verificó el paquete 4.3.1 desde la rama de lanzamiento (advertencia: myget fue muy lento para él - 5 minutos)
Estos son los pasos para validar:

Pruebe los paquetes más recientes en el feed de desarrollo de MyGet. Querrá utilizar la última compilación STABLE (no la versión preliminar) del paquete System.Net.Http.dll - 4.3.1 :
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

Puede usar paquetes de fuentes de desarrollo cambiando las fuentes de origen del paquete NuGet con herramientas de línea de comandos o Visual Studio.

Instrucciones:

Línea de comando:
Agregue lo siguiente en nuget.config, enelemento:

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

Estudio visual:
En VS, Tools-> Options-> Nuget Package Manager-> Package Sources -> Add, en Source, use esta url, https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

En cualquier caso, asegúrese de incluir la fuente de desarrollo de MyGet como la primera fuente de la lista.

[EDITAR]
Espere la redirección de enlace a 4.1.1.0 en su archivo de configuración:

<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>

He actualizado la publicación superior 'Plan de ejecución' con los siguientes pasos:

• 5.c Validación final / última de (la mayoría de) los ~ 7 escenarios de extremo a extremo: personas que ayudaron antes (o cualquier otra persona), ¿pueden responder una vez que verifiquen con la breve descripción del escenario? ¡Gracias! (casi estámos allí)
  
  
  
  • cc: @ annemartijn0 @karelkrivanek @jahmai @pollax @MikeGoldsmith @chadwackerman @dluxfordhpf @onovotny
  
  
• 5.d Publique el paquete en myget.org

Intenté verificar, pero recibo errores al intentar instalar ese paquete.

Cuando hice mi validación, lo hice con un proyecto completamente nuevo.

Sospecho que el error que está obteniendo con "No se pudieron actualizar las redirecciones de enlace" se debe a la degradación en las versiones de paquete y ensamblaje. Su proyecto actual parece estar basado en los paquetes de la rama [master]. System.Net.Http.4.4. * Es la numeración de paquetes de la rama [master] (parte de la versión preliminar de .NET Core 2.0). Tiene una versión de ensamblado para System.Net.Http que es 4.2. *.

El paquete System.Net.Http versión 4.3.1 es un paquete ESTABLE (no una versión preliminar) y está construido a partir de la rama de servicio de .NET Core 1.1 (compatible con la versión de servicio de .NET Core 1.1.1). Contiene un binario de System.Net.Http dll con una versión de ensamblado diferente.

Creo que el error que ha descubierto es cuando Visual Studio / NuGet está intentando reescribir sus redireccionamientos de enlace para la versión de ensamblado modificada de System.Net.Http.

Por lo tanto, puede intentar crear una nueva solución / proyecto. O quizás elimine sus redireccionamientos vinculantes y luego vuelva a colocarlos.

FYI. Mi registro de la instalación de mi paquete:

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

Hm, estoy confundido al probar. Actualicé a 4.3.1 y obtuve la siguiente redirección de enlace en mi 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>

¿Esperado?
Tal vez me perdí algo antes en el hilo, o tal vez esta es una de esas situaciones confusas de falta de coincidencia entre la versión de los paquetes y la versión dll.
También desinstalé el paquete, eliminé las redirecciones vinculantes y luego lo reinstalé y obtuve el mismo resultado.

Creación y ejecución de Works On My Machine ™ ️.

Por cierto, no estoy muy seguro de por qué esta versión pasó de 4.4 a 4.3.1, pero está bien.

La versión disminuyó en numeración porque la versión 4.4 será la más reciente, pero aún es una versión preliminar y se enviará como parte de .NET Core 2.0. @karelz le pidió a la gente que probara ese paquete primero porque la solución estaba allí primero.

Los paquetes 4.3. * Se basan en RTM .NET Core 1.1. Y habrá una versión de servicio de eso. Entonces, el paquete actualizado basado en esa base de código es 4.3.1 para System.Net.Http (ya que el paquete .NET Core 1.0 era 4.3.0 para System.Net.Http.

Tal vez me perdí algo antes en el hilo, o tal vez esta es una de esas situaciones confusas de falta de coincidencia entre la versión de los paquetes y la versión dll.

Sí, esto es confuso. La versión del paquete NuGet no es la misma que la versión de ensamblado .NET del binario.

Para el paquete System.Net.Http 4.3.1 NuGet, contiene un binario de System.Net.Http que tiene una versión de ensamblado 4.1.1.0. Entonces, está obteniendo los resultados correctos.

Gracias @pollax por la validación de su escenario de extremo a extremo (publicación superior actualizada).
Esperando un par de validaciones más , antes de que podamos enviarlo como solución final en nuget.org ... ya casi está ...

Mis disculpas por haber pasado por alto la redirección de enlace en las instrucciones (no me di cuenta de que cambiamos automáticamente la versión de ensamblaje debido a un potencial GAC, pero tiene sentido).
También disculpas que myget te obligue a entrar en todos los paquetes de myget. Estoy haciendo un seguimiento interno con la gente para averiguar si tenemos pasos para tomar un solo paquete de myget. Al menos para futuras verificaciones.

@davidsh , ¿pueden coordinar las validaciones de un extremo a otro mientras estoy fuera de servicio? Una vez que tengamos ~ 3 validaciones, pida a @leecow / @weshaggard que publique el paquete en nuget.org. ¡Gracias!

Hola chicos,

Un poco fuera de tema, pero solo quería dar un saludo al equipo aquí. Este tema ha sido muy activo y la respuesta a veces ha sido hostil. A pesar de la hostilidad, siento que el equipo de desarrollo lo manejó con clase.

Gracias por el apoyo, chicos y sigan con el buen trabajo. Los errores ocurren. Gracias por arreglarlo, entiendo que lleva tiempo.

Aquí hay otra confirmación de que la nueva versión soluciona el problema.

Usamos KeyVault, al pasar a 4.3.1 se solucionó el problema.

Hola, tengo este problema con SignalR. Pero, ¿cómo obtengo System.Net.Http 4.3.1? Solo veo 4.3.0 en
https://www.nuget.org/packages/System.Net.Http/

Vaya, mensajes perdidos sobre CoreFx: https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

Soluciona mi problema de SignalR.

Como han señalado otros, la alimentación es muy lenta. ¿Alguna posibilidad de obtener 4.3.1 en el canal nuget normal? Es sábado a la 1:30 pm y whoa .... (8 minutos esperando deps)

Intentando recopilar información de dependencia para el paquete 'System.Net.Http.4.3.1' con respecto al proyecto 'Translate \ Kumquat.Translate.Tests', apuntando a '.NETFramework, Version = v4.6'
La recopilación de información de dependencia tomó 5.85 minutos
Intentando resolver dependencias para el paquete 'System.Net.Http.4.3.1' con DependencyBehavior 'Lowest'
Se han detectado una o más restricciones de dependencia de paquetes sin resolver en el archivo packages.config existente. Todas las restricciones de dependencia deben resolverse para agregar o actualizar paquetes. Si estos paquetes se están actualizando, este mensaje puede ignorarse, de lo contrario, los siguientes errores pueden estar bloqueando la operación del paquete actual: 'System.Net.Http 4.3.0'
La resolución de la información de dependencia tomó 0 ms
Resolución de acciones para instalar el paquete 'System.Net.Http.4.3.1'
Acciones resueltas para instalar el paquete 'System.Net.Http.4.3.1'

Intentando recopilar información de dependencia para el paquete 'System.Net.Http.4.3.1' con respecto al proyecto 'Dict \ Kumquat.Dict.CE.Tests', apuntando a '.NETFramework, Versión = v4.6'
La recopilación de información de dependencia tomó 3.84 min
Intentando resolver dependencias para el paquete 'System.Net.Http.4.3.1' con DependencyBehavior 'Lowest'
Se han detectado una o más restricciones de dependencia de paquetes sin resolver en el archivo packages.config existente. Todas las restricciones de dependencia deben resolverse para agregar o actualizar paquetes. Si estos paquetes se están actualizando, este mensaje puede ignorarse; de ​​lo contrario, los siguientes errores pueden estar bloqueando la operación del paquete actual: 'System.Net.Http 4.3.0'
La resolución de la información de dependencia tomó 0 ms
Resolución de acciones para instalar el paquete 'System.Net.Http.4.3.1'
Acciones resueltas para instalar el paquete 'System.Net.Http.4.3.1'

@karelz Azure Storage API escenario revalidado con la versión 4.3.1 de MyGet.

Lo siento por no haber respondido antes.

La recopilación de dependencias de https://github.com/NuGet/Home/issues/4448

Lo imaginé. ¿Alguna ETA para ingresarlo en nuget.org?

@davidsh Hola David, ¿será esta la semana en la que 4.3.1 llegará a nuget? Tengo un proyecto bastante complejo y parece que el tiempo de espera debe escalar con la cantidad de paquetes en el proyecto. Aún así, tener una solución es mejor que nada. Supongo que puedo copiar el nupkg en alguna parte.

Intentando recopilar información de dependencia para el paquete 'Kumquat.Translate.8.6.2' con respecto al proyecto 'qi', apuntando a '.NETFramework, Versión = v4.6'
La recopilación de información sobre la dependencia tomó 8,76 minutos

Más recientemente 8,76 min.

@davidsh Esto acaba de aparecer en la lista de correo de OwlMQ. Puedo informar que el paquete actualizado lo resuelve.

Muchas gracias al equipo por adelantarse a esto. ¡Impresionante trabajo!

Gracias por todas las validaciones del paquete.

El paquete System.Net.Http 4.3.1 se ha promocionado a NuGet.org.

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

Hm, muy extraño: el cliente RavenDB ahora se queja de que no puede encontrar el ensamblaje 4.1.1

EDITAR: Advertencia: Acme.Core hace referencia a RavenDB.Client y Acme.Main hace referencia a Acme.Core. VS2015 no copiará System.Net.Http como dependencia, pero la redirección de enlace está ahí -> boom. ¿Es este el comportamiento esperado? Solución bastante simple, por supuesto ...

Cerrando el problema como arreglado. ¡Gracias @davidsh y @CIPop por su trabajo aquí!
Gracias a todos por su paciencia. Y nuestras disculpas por el retraso. Siguiente paso: post-mortem (como se prometió) - por favor, dame ~ 2 semanas para conocer todos los detalles históricos por aquí ...

@georgiosd , ¿puede presentar un nuevo problema y proporcionar una reproducción? (idealmente comenzando con un nuevo proyecto)

@karelz ¡ gracias!

FYI:

• Actualicé la mayoría de las publicaciones con una lista de escenarios verificados (en caso de que alguna vez se necesite en el futuro) y un enlace al paquete.
• Para el futuro, planeo mirar los pasos para usar solo un paquete en particular de myget en lugar de todo el feed, para solucionar el problema de obtener todo lo último (y también los problemas de lentitud). Esperemos que no lo necesitemos tan pronto.

@karelz pregunta rápida: ¿dónde encontraremos información sobre la autopsia, cuando esté completa? ¿En este hilo _o_ otro hilo / lugar?

@PureKrome Definitivamente actualizaré este hilo; es más fácil para todos los que ya están interesados ​​recibir la notificación. Además, mi objetivo no es restar importancia a la autopsia y ocultarla a la gente.
Sin embargo, lo más probable es que cree un nuevo problema para la discusión (como espero) ;-).
En un nivel alto, planeo cubrir:

1. ¿Cómo llegó el problema al lanzamiento? ¿Cómo prevenir tal situación en el futuro?
2. ¿Por qué tardó 6 meses en solucionarse? ¿Por qué no se trató / comunicó como un problema de alto impacto antes? ¿Cómo reconocer y reaccionar ante problemas de alto impacto en el futuro?
3. Otras preocupaciones (por ejemplo, comunicación general)

Además, si encontramos algo roto / que no funciona correctamente con 4.3.1 (por ejemplo, @georgiosd 's find arriba ), deberíamos mencionarlo aquí para darnos cuenta, pero tomemos los detalles en un tema por separado para facilitar la discusión / seguimiento.

Gracias @karelz (y el equipo de MS). Entonces permaneceré suscrito a este hilo. 👍

¡Sigue peleando la buena batalla, equipo! 💯

También tengo que agradecer a @ chadwackerman2

Felicidades a todos una vez más por resolver uno de los errores más molestos en la historia de .NET :)

@karelz feliz de hacerlo, pero me preguntaba si este es de alguna manera el comportamiento esperado.

@georgiosd No lo sé, será más fácil discutirlo en un número separado ;-) (incluida la participación de los expertos adecuados)

Gracias por impulsar este trabajo, @karelz

Sé que llegué tarde con la autopsia, mis disculpas.
No lo olvidé, simplemente no lo logré todavía debido a prioridades más altas (planificación / seguimiento 2.0, profundizando en el problema de redirecciones vinculantes que también surgió aquí - dotnet / runtime # 17770)
Me esforzaré mucho para terminar la autopsia en las próximas 1-2 semanas.

Hola, Bien hecho a todos los involucrados en resolver esto. No puedo decir que entiendo todas las tuercas y tornillos, pero una cosa que aún no entiendo es por qué esto solo sucedió cuando actualizamos nuestra solución de VS 2015 Update 3 a VS 2017. La solución en cuestión era un conjunto de proyectos ASP.Net Core dirigidos el marco .net 4.6. El problema se desencadenó con el uso de Azure KeyVaultClient.

Gracias, Donal

Hola @karelz , he estado investigando y trabajando dos noches seguidas hasta ahora, pero no puedo solucionar este problema. Todos mis paquetes System.Net.Http se han actualizado a la versión 4.3.1 pero siguen teniendo el mismo error. Por favor ayúdame, no sé qué más probar ni adónde ir. ¡Gracias!

FileNotFoundException: no se pudo cargar el archivo o ensamblado 'System.Net.Http, Version = 4.1.1.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a'. El sistema no puede encontrar el archivo especificado.

Un aquí mi .csproj

netcoreapp1.1

$ (PackageTargetFallback); portable-net45 + win8 + wp8 + wpa81;

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

@parismiguel lamento escuchar eso :(. ¿Tiene bindingRedirects de 4.0.0.0 a 4.1.1.0 en su aplicación?

<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> 

Estamos investigando cómo hacer que la historia de bindingRedirects sea más fluida: https://github.com/dotnet/corefx/issues/9846#issuecomment -287941109

ACTUALIZACIÓN: Mirando su error, parece que el problema es que no se encontró su versión 4.1.1.0. ¿Puede consultar el directorio de su aplicación si la versión de ensamblaje correcta está realmente allí?

@karelz eso fue rápido, ¡muchas gracias! Vi las cosas de bindingRedirects en publicaciones anteriores, pero no estoy seguro de dónde colocarlo ... Lo intenté dentro de mi .csproj pero tengo errores (adjuntos como .txt) Con respecto a la versión 4.1.1.0 I ' No estoy seguro de seguir ... ¿No se supone que debo actualizarlo a 4.3.1?

IbmVcaCore.csproj.txt

Las redirecciones de enlace van a su archivo app.config o web.config:

Vea esto para más detalles:
https://msdn.microsoft.com/en-us/library/7wd6ex19 (v = frente a 110) .aspx

Hola @davidsh , ¡gracias por tu ayuda!
Mi proyecto no tiene ninguno de esos archivos ... es una compilación de proyecto NET Core con la plantilla de Visul Studio 2017 ... ¿qué me falta?

Re: 4.3.1 vs 4.1.1 - 4.3.1 es la versión del paquete NuGet, 4.1.1.0 es la versión de ensamblaje (ildasm / ILSpy / VS se lo mostrará).
Las versiones NuGet frente a ensamblado son un poco confusas y es difícil conectar cuál pertenece a cuál. Está en mi lista de cosas para profundizar en si podemos conectar los puntos a través de la documentación (por ejemplo, en la página NuGet).

Si está en .NET Core, no necesita bindingRedirects y, además, este problema NO le afecta en absoluto. Este problema es específico de Desktop (= .NET Framework).
El paquete 4.3.1 NuGet modificó solo su ensamblado de escritorio, no el ensamblado de .NET Core.

Si aún tiene problemas, envíe un nuevo error y etiquéteme allí. Este problema ha sido criticado por mucha gente (ya que fue impactante), su problema no está relacionado con él (al menos se ve así), así que seamos amables con las notificaciones / bandejas de entrada de GH de todos.

Para todos : he creado un nuevo número dotnet / corefx # 17522 para realizar un seguimiento de la autopsia que prometí.
Lamentablemente, todavía no hice mucho progreso :( ... pero al menos todos los interesados ​​pueden comenzar a seguir ese tema y evitar el ruido potencial sobre este tema (tratando de ayudar a las personas a concentrarse en lo que les interesa).

@karelz gracias, seguiré tus instrucciones y publicaré en tu nuevo rastreador de problemas. Saludos.

@parismiguel no está en el nuevo número que creé, por favor cree uno nuevo. El que creé (# 17522) es para análisis post-mortem por qué este problema (# 11100) tardó tanto en resolverse.

gracias @karelz y mis más sinceras disculpas por alterar este tema .... espero obtener ayuda en el nuevo como se indica. Un cordial saludo,

Parecía haberme encontrado con esto a través de una tormenta perfecta.

Estoy usando la vista previa de Azure Functions con una combinación de Azure Key Vault (2.0.6) y Octopus Client (4.15.3).

He intentado actualizar a System.Net.Http a 4.3.2 sin embargo, todavía falla al intentar usar Key Vault .

¿Algun consejo?

@karelz

¿Puede asegurarse de que el ensamblaje del paquete nuget 4.3.2 se use realmente en tiempo de ejecución? (se corrigió en 4.3.1)