Pregunta

Cada vez que construyo o publico un sitio web, Visual Studio intenta revisar el archivo web.config para que pueda agregar numerosos ensamblajes que no son necesarios.

En otras palabras:

web.config antes:

<configuration>
   <system.web>
      <compilation>
         <assemblies>
         </assemblies>
      </compilation>
   </system.web>
</configuration>

web.config después de:

<configuration>
   <system.web>
      <compilation>
         <assemblies>
             <add assembly="Microsoft.ReportViewer.Common... />
             <add assembly="Microsoft.ReportViewer.WinForms... />
             <add assembly="System.DirectoryServices... />
             <add assembly="System.Windows.Forms... />
             <add assembly="ADODB... />
             <add assembly="System.Management... />
             <add assembly="System.Data.OracleClient... />
             <add assembly="Microsoft.Build.Utilities... />
             <add assembly="Microsoft.ReportViewer.ProcessingObjectModel... />
             <add assembly="System.Design... />
             <add assembly="Microsoft.Build.Framework... />
         </assemblies>
      </compilation>
   </system.web>
</configuration>

No se requiere ninguno de estos ensamblajes, y la mayoría no existe en los servidores de prueba o producción de destino.

Sigo eliminándolos cada vez que compilo, pero se está volviendo real molesto muy rápido.

Ahora mismo, mi solución es dejar web.config solo para lectura, por lo que Visual Studio no puede agregarle ensamblados.


Actualizar

Capturas de pantalla como prueba:

Páginas de propiedades del proyecto anteriores :

 texto del enlace

Web.Config antes:

 texto alternativo

Páginas de propiedades del proyecto después de:

 texto alternativo

Web.config después de:

 texto alternativo

Actualización dos

Cabe señalar explícitamente que el sitio web funciona sin que se agreguen estas referencias extrañas. Mi solución provisional es mantener web.config solo para lectura y presionar Cancelar cada vez que Visual Studio se queje de que es solo de lectura cuando intenta modificarlo. Si puedo evitar que Visual Studio intente modificarlo en primer lugar ...


Actualización tres

Parece que no es posible. Alguien puede sentirse libre de dar la respuesta correcta, " No puede impedir que Visual Studio agregue ensamblados a su web.config . & Quot; y lo marcaré.

La única razón por la que mantengo la pregunta es que, con suerte, alguien conozca la opción súper secreta, la clave de registro, la configuración del proyecto o la solución, para decirle a Visual Studio que deje de pensar.


Actualizar cuatro

No acepté la respuesta aceptada y la aceptaría si pudiera. Todavía estoy esperando la panacea. Pero en este momento me estoy inclinando hacia:

  • Respuesta: no se puede hacer ( manu08 )
  • Solución alternativa: clave de registro de ensamblajes de GAC filtrada ( Nebakanezer )

¿Cómo puedo evitar que Visual Studio agregue ensamblados a mi web.config?

Referencias

¿Fue útil?

Solución

Usé VS2005 para editar un .net 1.1 (VS2003) .aspx y lo guardé, entonces el web.config misteriosamente tendrá la red. Montajes 2.0 agregados:

Si usé VS2008 o VS2010, esto no sucede. Así que creo que esto es un error en el IDE VS2005.

Otros consejos

Tal vez la " Avatar DotNet Library " está haciendo referencia a esas asambleas por sí mismo. Las referencias de un ensamblado al que se hace referencia son necesarias para implementar correctamente un proyecto. De lo contrario, ¿cómo podría funcionar el ensamblaje al que se hace referencia?

Tenga en cuenta que es posible que su ensamblado referenciado no use sus propias referencias, aunque existan.

Editar: puedes usar la gran herramienta " .Net Reflector " para comprobar esto.

Tuve este problema con Visual Studio 2005 (pero me complace informar que la solución funciona para VS 2008, vea el texto en negrita a continuación). Hay una sección de registro que comprueba VS antes de agregar ensamblajes al archivo web.config.

Aquí está la clave:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Projects\{E24C65DC-7377-472B-9ABA-BC803B73C61A}\FilteredGACReferences

Entonces, digamos que no desea que Visual Studio agregue el ensamblado Microsoft.VisualStudio.Designer.Interfaces a su web.config. Agregue la siguiente entrada a su registro y estará listo.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Projects\{E24C65DC-7377-472B-9ABA-BC803B73C61A}\FilteredGACReferences\Microsoft.VisualStudio.Designer.Interfaces

Funcionó perfectamente para mí. Y sí, el resto de tu equipo tendrá que hacer lo mismo, pero al menos no tienes que eliminar las entradas manualmente cada vez que lo hagas :)

Para que funcione en VS 2008, solo cambia la 8.0 en la ruta de registro a 9.0

Convierte tu " Sitio web " proyecto a una " Aplicación Web " proyecto.

Un " Sitio web " no tiene un archivo de proyecto, por lo que contiene todas las referencias de ensamblaje en web.config. Un " Proyecto Web " tiene un archivo de proyecto, y todas las referencias se almacenan en el archivo de proyecto.

Eliminar las referencias.

  • Si es una aplicación web: puede ver las Referencias en Explorador de soluciones .

  • Si es un sitio web: haga clic con el botón derecho en el proyecto en el Explorador de soluciones y luego seleccione Páginas de propiedades . Administrarlos allí.

HTH

Si un conjunto compartido hace referencia a ellos, también se agregarán al proyecto de llamada.

Dado que la biblioteca de Avatar hace estas otras referencias, Visual Studio también agrega estas referencias al proyecto principal. De lo contrario, una llamada a la biblioteca de Avatar podría fallar ya que falta la referencia que necesita.

Bueno, esto puede parecer un truco, pero dados sus requisitos, otra opción sería cargar el ensamblaje de Avatar dinámicamente usando Assembly.Load o LoadFrom en tiempo de ejecución. Esto mantendría una referencia fuera del proyecto principal y luego debería evitar las líneas de referencia adicionales en web.config. Sin embargo, esto solo sería realmente práctico si solo estuvieras usando una pequeña cantidad de clases del proyecto Avatar. Haría un tercer proyecto al que ambos proyectos hicieron referencia que contenía interfaces que una o más clases de Avatar implementaron para que el proyecto principal mantenga una escritura estricta al manejar instancias de Avatar. Admito que esto podría ser mucho más trabajo que las respuestas enviadas anteriormente. Si está interesado en este método, busque en google para crear complementos en .Net

Mientras esté utilizando un sitio web, en lugar de una aplicación web, no conozco ninguna forma de evitar que Visual Studio agregue ensamblados a su web.config. Este mismo tipo de problema también ocurre con las soluciones de mi empresa.

No puedes evitar que Visual Studio agregue ensamblados a tu web.config.

Lo sentimos, no puedes evitar que Visual Studio agregue ensamblados a tu web.config , pero no todo está perdido.

He golpeado esto en el pasado; alguien ha agregado algunas referencias (incluido WinForms) a un ensamblaje de acceso a datos de bajo nivel. El sitio web utilizó el ensamblaje de acceso a datos de bajo nivel y, por lo tanto, se agregaron WinForms, etc., al archivo web.config.

La solución fue mover su código al ensamblaje correcto y eliminar la referencia incorrecta.

Si no puede ordenar el ensamblaje que tiene las referencias no deseadas y sabe que no está llamando a un código que depende de las referencias no deseadas. Entonces puedes (ninguno de estos es bueno)

  • Escriba una acción de instalación personalizada que automatice la eliminación de estas referencias de ensamblaje no deseadas de web.config
  • Escriba una acción MSBUILD personalizada para eliminarla en el momento de la compilación
  • Use un archivo web.config escrito a mano diferente cuando se instale la aplicación.

Puede llevar siglos descubrir por qué Visual Studio agrega una referencia al archivo web.config. Tiene que revisar manualmente TODOS los ensamblajes que se usan directamente o indirectamente en el sitio web.

Sé y aprecio por qué Microsoft inventó los sitios web en ASP.NET 2.0, pero a veces simplemente apestan . Si es práctico para usted, convierta su sitio en un Proyecto de aplicación web, y los problemas como éste desaparecerán.

Si eso no es práctico para usted, intente re-factorizar tanto código como sea posible en un proyecto de biblioteca de clases por separado. Cualquier referencia que pueda mover fuera del sitio web y dentro de la biblioteca de clases reducirá los cambios en web.config .

EDITAR: Para aclarar, en un sitio web, el compilador aspnet compila todo (marcado, código subyacente, el lote), por lo que todas las referencias de ensamblaje deben ir a web.config . Sin embargo, en un proyecto de aplicación web, el compilador C # o VB compila los archivos de código subyacente en una DLL separada, a la que el compilador aspnet hace referencia cuando compila el marcado. En este escenario, los ensamblados a los que solo se hace referencia en archivos de código subyacente entrarán en la DLL de código subyacente y no tocarán web.config . Solo los ensamblajes a los que se hace referencia directamente en el marcado entrarán en web.config .

No creo que pueda evitar que Visual Studio agregue automáticamente referencias a ensamblados a los que otros hacen referencia.

Una solución es crear un proyecto de instalación web con una acción personalizada que automatice la eliminación de estas referencias de ensamblaje no deseadas de web.config .

Esos son todos los ensamblajes requeridos por su proyecto, de alguna forma o forma, y ??son la ayuda de la compilación que ASP.NET hace en sus páginas en tiempo de ejecución. Probablemente los esté importando el código que esté usando en su proyecto u otra biblioteca que los esté utilizando.

Pero de acuerdo con la documentación . Estos son los conjuntos definidos en su web.config global que se pueden encontrar en C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG :

<assemblies>
    <add assembly="mscorlib" />
    <add assembly="System, ..." />
    <add assembly="System.Configuration, ..." />
    <add assembly="System.Web, ..." />
    <add assembly="System.Data, ..." />
    <add assembly="System.Web.Services, ..." />
    <add assembly="System.Xml, ..." />
    <add assembly="System.Drawing, ..." />
    <add assembly="System.EnterpriseServices, ..." />
    <add assembly="System.Web.Mobile, ..." />
    <add assembly="*" />
</assemblies>

Si observa, se está agregando una referencia a assembly = " * " . Y si leyó la documentación sobre este comando, dice:

  

Opcionalmente, puede especificar la   asterisco (*) carácter comodín para agregar   cada asamblea dentro de lo privado   Caché de montaje para la aplicación.   que se encuentra ya sea en el \ bin   subdirectorio de una aplicación o en   la instalación de .NET Framework   directorio   (% systemroot% \ Microsoft.NET \ Framework \ version).

Esto significa que ya se incluirá cualquier ensamblaje en su directorio / bin o en el directorio de instalación de .NET Framework.

Lo que esto me dice acerca de su problema es que los ensamblados que se están incluyendo ya están referenciados de alguna manera a su proyecto. Y probablemente provengan de la Avatar Dot Net Library o de algunos controles en su página. Comprueba las " Referencias " carpeta en su proyecto de Visual Studio en la Biblioteca de Avatar para estas referencias que no desea. Porque ahí es donde el proceso de compilación obtiene estas bibliotecas.

En otras palabras, si no desea que se incluyan, elimine los proyectos de referencia de todas las referencias de estas bibliotecas.

Alternativamente, puedes usar un analizador de MSBuild XML para eliminar esa sección de web.config cada vez que ejecutes el proceso de compilación. Personalmente utilizo una tarea llamada XmlUpdate para modificar ciertas partes de mi web.config para que esté lista para la producción. Si desea hacer lo mismo, forma parte de Tareas de la comunidad de MSBuild .

Si está ejecutando en una máquina vista o server 08, puede usar la utilidad de línea de comandos appcmd para eliminarla después de la reconstrucción en lugar de eliminarla manualmente.

http://technet.microsoft.com/ en-us / library / cc772200 (WS.10) .aspx http://learn.iis.net/page.aspx / 114 / getting-started-with-appcmdexe /

consulte http://msdn.microsoft.com/en-us/ library / ms178728.aspx

ahí se explica que lo que se ve en la Página de propiedades no es todo, las referencias implícitas también existen en el archivo Machine.config y se agregan en el momento de la compilación. Espero que esto ayude.

Empezaría marcando " utilizando " las declaraciones en sus archivos de código, así como las referencias en sus archivos .aspx, .ascx. Parece que ha hecho referencia a algunos de estos (sé que algunos se agregan de forma predeterminada desde las plantillas Agregar nuevo elemento.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top