tutorial - visual studio code javascript

Visual Studio 2010: publique archivos javascript minificados en lugar de los originales (5)

Tengo una carpeta de Scripts, que incluye todos los archivos .js utilizados en el proyecto. Usando la tarea Ajax Minifier, genero archivos .min.js para cada uno. Dependiendo de si la aplicación se está ejecutando en modo de depuración o versión, incluyo el archivo .js original, o el minificado.

La carpeta Scripts se ve así:

Scripts/script1.js Scripts/script1.min.js // Outside the project, generated automatically on build Scripts/script2.js Scripts/script2.min.js // Outside the project, generated automatically on build

Los archivos .min.js están fuera del proyecto (aunque en la misma carpeta que los archivos originales) y no se copian en la carpeta de destino cuando publicamos el proyecto.

No tengo experiencia alguna en el uso de tareas de compilación (bueno, aparte de incluir la tarea de minificación), por lo que agradecería que alguien me aconsejara cuál sería la forma correcta de:

Copie los archivos .min.js en la carpeta de destino cuando publique la aplicación desde Visual Studio.
Eliminar / No copiar los archivos js originales (esto no es vital, pero prefiero no copiar los archivos que no se usarán en la aplicación).

Gracias,

Editar: A partir de las respuestas, veo que omití algunos detalles, y que quizás estoy buscando la solución incorrecta al problema. Agregaré los siguientes detalles a la pregunta:

Si es posible, preferimos no crear scripts de copia en el proceso de compilación de la solución. Claro, lo consideramos, pero estábamos usando proyectos de implementación web hasta ahora, y preferimos comenzar a usar la nueva característica Publicar de VS2010 (que se supone que reemplaza estos proyectos) que manualmente agregar comandos de copia a la tarea de compilación.
Los archivos * .min.js no están incluidos en el proyecto porque no pueden estar en el sistema de control de origen (TFS en este momento). Son archivos generados durante la compilación, y sería similar a incluir la carpeta ''bin'' en el TFS (incluidos los problemas que causaría). ¿Tal vez deberíamos crear los archivos min en una carpeta diferente y tratarlos como ''bin''? (¿Es eso posible?)

Es probable que desee echar un vistazo a Build Events , con el que puede especificar una línea de comando para ejecutar post-build. Su pregunta es, además, similar a these questions .

Para la copia real, puede simplemente hacer uso del comando COPY .

Este artículo sobre "Automatically Minify, Combine, Compress, and Cache * .js and * .css Files en su proyecto ASP.NET" puede quizás ayudarlo

http://www.codeproject.com/KB/aspnet/CssAndJavaScriptOptimizer.aspx?display=Print

No estoy seguro de si este enfoque sería útil en esta situación, pero podría imaginarlo ... Puede modificar archivos csproj para, por ejemplo, influir en qué archivos se deben incluir en un determinado tipo de compilación.

Con cierto tipo, me refiero al Configuration Manager.

Debug and Release son los predeterminados pero nada le impide crear nuevos. Según la configuración seleccionada, puede tener diferentes archivos que forman parte de la configuración y supongo que podría publicar diferentes archivos de esa manera. Describí esa estrategia en mi blog aquí: http://realfiction.net/go/130

Si quiere hacer una minificación de Javascript a través de Visual Studio, esto le permitirá comenzar: http://encosia.com/2009/05/20/automatically-minify-and-combine-javascript-in-visual-studio/

De lo contrario, recomendaría una herramienta que pueda combinar y minificar Javascript automáticamente. Las dos herramientas que he analizado son Combres and Combres Justin Etheredge . Estoy usando Bundler en mi proyecto actual y uno de mis colegas está usando Combres. Bundler es un poco más fácil de usar pero tiene menos que Combres. Con Bundler si la depuración está desactivada en web.config, no se minimiza ni se combina, lo que significa que puede depurar el javascript en su entorno de desarrollo.

PS Bundler se renombró a SquishIt.

Editar (2012 de octubre): ASP.NET 4.5 ahora incluye Paquetes y minificación . La versión actual no admite la generación dinámica de javascript muy bien, pero de lo contrario es bastante utilizable y, por ejemplo, vigila el sistema de archivos para realizar cambios como se describe a continuación; antes de rodar tu propia compresión, ¡prueba eso!

Respuesta anterior:

En lugar de implementar esto en tiempo de compilación, le sugiero que lo haga en tiempo de ejecución. Esto tiene una serie de ventajas:

Puede incluir parámetros de depuración que desactivan la combinación y la minificación para permitir una identificación más fácil de los errores. Esto también le permite ejecutar con menos diferencia entre el entorno de desarrollo y producción.
Obtienes cierta flexibilidad. He podido corregir errores dos veces a través de una corrección de solo script que puede activarse directamente. Para errores simples pero críticos esa es una buena opción.
Es un poco más fácil de implementar: ya tienes la experiencia en la implementación de respuestas http, que se aplica muy bien aquí.
Puede rastrear la fecha de última modificación de las secuencias de comandos involucradas, y no solo utilizar eso para establecer los ETags y lo que sea apropiado (lo que IIS puede hacer también), sino establecer una fecha de caducidad futura. Luego, en lugar de vincular el scipt real (ya sea minimizado o no), puede vincular el script con un token corto en la cadena de consulta, de esa forma los clientes no necesitan verificar si el js se ha actualizado. Cuando lo haya hecho, las páginas se vincularán a un "nuevo" archivo de script que, de todos modos, debe solicitarse por separado. (Esto es posible en scripts de compilación, pero más complicado).
Un proceso de construcción complejo a menudo tiene costos ocultos. No solo toma más tiempo para ejecutarse, ¿pero qué sucede cuando desea actualizar su herramienta de automatización de compilación? ¿Cuándo cambia las versiones de IIS o Windows? ¿Cuándo migra a VS 2010? ¿Qué tan fácil es poner a los nuevos desarrolladores al tanto?

Este es el bosquejo del proceso que sigo:

Especifico que dos directorios contienen solo css y js comprimibles. En la instanciación del dominio de aplicación o poco después a través de un constructor estático, una clase encuentra el contenido de esos directorios y crea un FileSystemWatcher para observar los cambios.
Todos los archivos se leen por orden de nombre de archivo (usando prefijos como 00_jquery.js 10_init.js etc. ayuda a controlar el orden aquí). La lista de nombres de archivos se almacena con fines de depuración.
Todos los archivos se combinan mediante la concatenación de cadenas, luego se minimizan con YUI y luego se comprimen a través de GZipStream . Un token específico de la versión se calcula con la última fecha de la última modificación o con el resumen del resultado.
El resultado de la compresión (matriz de bytes, nombres de archivo y token específico de la versión) se almacena en una variable de clase estática (protegida por un lock ). Si el vigilante del sistema de archivos detecta una actualización, el paso 2 comienza de nuevo y se ejecuta en segundo plano hasta que se complete la compresión, de ahí el bloqueo.
Cualquier página que desee incluir el javascript combinado (y / o css) llama a la variable estática compartida. Si estamos en modo de depuración, eso genera una etiqueta de guión (o enlace) para cada nombre de archivo almacenado en el paso dos; de lo contrario, esto genera una sola etiqueta de guión (o enlace) para un Uri manejado por un IHttpHandler personalizado. Todos los Uri incluyen el token específico de la versión en la cadena de consulta; esto es ignorado tanto por el controlador de archivos estáticos de IIS como por el manejador de http personalizado para la versión combinada combinada, pero hace que el almacenamiento en caché sea sencillo.
En un IHttpHandler personalizado, cuando se recibe una solicitud del javascript (o css) combinado, se establece el encabezado Content-Encoding: gzip y una fecha de vencimiento futura. A continuación, la matriz de bytes precomprimidos se escribe directamente en la secuencia http a través de context.Response.OutputStream .

Al usar ese enfoque, no necesitará jugar con las opciones de web.config cada vez que agregue o elimine un archivo de script; puede actualizar los scripts mientras la aplicación se está ejecutando y los clientes los solicitarán en la vista de la página siguiente, pero aún obtendrá un comportamiento de caché óptimo ya que los navegadores ni siquiera enviarán una solicitud If Not Notified debido al encabezado de caducidad. Por lo general, la compresión de scripts debería tomar alrededor de un segundo y el resultado comprimido debería ser tan pequeño que la sobrecarga de memoria de la variable estática es insignificante (como máximo unos 100 KB para una cantidad realmente grande de scripting / css).