asp.net - reparar - reparador de archivos dll windows 7 gratis

System.Web.MVC no se ha copiado en la carpeta bin desde MS14-059. ¿Cómo protegerse contra la creación de compilaciones con archivos DLL que faltan como resultado de las actualizaciones de Windows? (3)

Esta mañana se informó que nuestra aplicación web en nuestro servidor de QA estaba completamente rota con el siguiente error reportado en Web.config:

No se pudo cargar el archivo o ensamblado ''System.Web.Mvc, Version = 5.1.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35'' o una de sus dependencias. El sistema no puede encontrar el archivo especificado

Recordando haber visto una actualización de Windows que mencionaba a MVC, investigué un poco y encontré a lots people reporting una reciente actualización de Windows rompiendo MVC.

Después de investigar a fondo esas preguntas y nuestro servidor, parece que lo que nos ha mordido no coincide con lo que hay en esas otras preguntas, pero sí parece estar relacionado. Esto es lo que creemos saber:

Nuestra aplicación que está rota usa ASP.NET MVC 5.1
MVC fue instalado a través de NuGet
Nuestros servidores BuildServer y QA NO tienen MVC 5.1 instalado (por lo tanto, no GAC''d)

Lo que creemos que se ha roto ha causado que se cree la "mala construcción":

Se instaló un parche para MVC 5.1 en el BuildServer a través de Windows Update a pesar de no tener MVC 5.1 instalado en el GAC
El parche ha puesto la versión "actualizada" de MVC 5.1 en el GAC
CopyLocal = true se ignora cuando una DLL está en el GAC; por lo tanto, desde el parche, esto significa que las versiones de nuestra aplicación desde BuildServer ya no tienen System.Web.MVC en la carpeta de salida
Como System.Web.MVC no está en el GAC en nuestros servidores de control de calidad (aún no se han corregido), la aplicación ahora falla, porque System.Web.MVC no se puede encontrar.

Suponiendo que el comportamiento descrito arriba es correcto, esto significa que cada vez que MS preste servicio a NuGet DLL a través de Windows Update que no tenemos en el GAC , nuestro BuildServer comenzará a producir compilaciones incompletas (omitiendo aquellas DLL que se han inyectado al GAC) .

La actualización a MVC 5.2 resuelve este problema (probablemente porque no fue parcheado y, por lo tanto, no se inyectó en el GAC); la DLL ahora se copia a la carpeta de salida. No hay cambios en la diferencia que se actualizó a 5.2.2 excepto por los cambios en el número de versión (no se ha agregado / editado específicamente ningún nodo <Private> ).

No deseamos iniciar GACing todo, ni crear pasos de compilación manual para copiar todas nuestras DLL en la carpeta bin solo en caso de que MS las parchee.

Entonces, ¿qué podemos cambiar hoy para asegurarnos de que nunca terminemos sin BuildServer produciendo compilaciones falsas de vuelta si MS remueve otras DLL en el futuro?

Se instaló un parche para MVC 5.1 en el BuildServer a través de Windows Update a pesar de no tener MVC 5.1 instalado en el GAC

Sí, este comportamiento es en realidad por diseño. Consulte http://blogs.msdn.com/b/dotnet/archive/2014/01/22/net-4-5-1-supports-microsoft-security-updates-for-net-nuget-libraries.aspx .

El parche ha puesto la versión "actualizada" de MVC 5.1 en el GAC

Si eso es correcto; es como el parche obtiene el código actualizado para ejecutarse en lugar del código anterior. Ver https://technet.microsoft.com/en-us/library/security/ms14-059 .

CopyLocal = true se ignora cuando una DLL está en el GAC; por lo tanto, desde el parche, esto significa que las versiones de nuestra aplicación desde BuildServer ya no tienen System.Web.MVC en la carpeta de salida

No exactamente. Lo que realmente ocurre es que un proyecto que anteriormente era CopyLocal = true cambia a CopyLocal = false. CopyLocal se puede configurar de dos maneras: 1) si hay una configuración explícita <Private>True</Private> en el archivo .csproj, o 2) de manera predeterminada, si no existe tal configuración (los ensamblados GAC no hacen CopyLocal por defecto, otros conjuntos sí).

Entonces, lo que parece haber sucedido en este caso es que su archivo de proyecto no tenía esta configuración en el archivo csproj. Como resultado, la GUI mostró la configuración basada en el valor predeterminado evaluado antes del parche (CopyLocal = true) pero luego de instalar el parche, la GUI ahora mostrará el nuevo valor predeterminado para un ensamblado GAC (CopyLocal = false )

Como System.Web.MVC no está en el GAC en nuestros servidores de control de calidad (aún no se han corregido), la aplicación ahora falla, porque System.Web.MVC no se puede encontrar.

Eso es correcto.

Suponiendo que el comportamiento descrito arriba es correcto, esto significa que cada vez que MS preste servicio a NuGet DLL a través de Windows Update que no tenemos en el GAC, nuestro BuildServer comenzará a producir compilaciones incompletas (omitiendo aquellas DLL que se han inyectado al GAC) .

Para cualquier referencia .csproj sin una configuración explícita <Private>True</Private> , eso es correcto. Además, tenga en cuenta que el uso de NuGet para actualizar su referencia MVC puede eliminar esta configuración, incluso si ya estaba presente. Ver http://nuget.codeplex.com/workitem/4344 .

La actualización a MVC 5.2 resuelve este problema (probablemente porque no fue parcheado y, por lo tanto, no se inyectó en el GAC); la DLL ahora se copia a la carpeta de salida. No hay cambios en la diferencia que se actualizó a 5.2.2 excepto por los cambios en el número de versión (específicamente no se agregó / editó ningún nodo).

Eso es correcto. Como MVC 5.2 no está GAC''d, incluso sin una configuración <Private>True</Private> explícita, el valor predeterminado de este ensamblado no GAC será CopyLocal = true.

No deseamos iniciar GACing todo, ni crear pasos de compilación manual para copiar todas nuestras DLL en la carpeta bin solo en caso de que MS las parchee. Entonces, ¿qué podemos cambiar hoy para asegurarnos de que nunca terminemos sin BuildServer produciendo compilaciones falsas de vuelta si MS remueve otras DLL en el futuro?

Lo mejor que puedes hacer hoy es:

Establezca las configuraciones explícitas <Private>True</Private> en su archivo .csproj para todas sus referencias de conjunto de paquetes NuGet.
Hasta que se solucione NuGet bug # 4344, cada vez que use NuGet para actualizar una referencia de paquete, regrese a su archivo .csproj y vuelva a agregar la configuración explícita <Private>True</Private> .

Creo que este problema se aborda en las herramientas de desarrollo web de .Net y en el blog de la interfaz de usuario aquí: link

No voy a repetir todo aquí, ya que el tema y la resolución se explican bastante bien en ese enlace.

Sin embargo, solo para repetir los puntos clave, lo que debería explicar por qué sucedió esto:

Como parte del parche KB2994397 MVC 5.1 se agregó al GAC.
Parece que hay un error NuGet que restablece el indicador CopyLocal. (ver link ) Esto significa que cuando una máquina con el parche anterior se despliega en una máquina sin parche, ¡se romperá!
MVC 4 ha tenido su número de versión de ensamblado incrementado por la misma actualización de seguridad - MS14-059 (por lo que NO se usará la versión GAC) Esto explica por qué la versión MVC 4 todavía funciona, a pesar de estar en el GAC.

link una nota sobre este tema en mi blog: link .

Su análisis del problema es correcto con respecto al dinero, de forma predeterminada, el indicador de Copiar local se establece en falso cuando el ensamblaje está en el GAC, configurarlo manualmente para que sea cierto debería solucionar este problema.

La actualización a 5.2.2 es aún mejor, usted obtiene los beneficios de la nueva versión además de la corrección de seguridad.