¿Cómo comparto recursos web comunes entre aplicaciones web en Visual Studio?

Question

Tengo tres proyectos de aplicaciones web que comparten una biblioteca común de controles de servidor personalizados. Compartir el código detrás de los archivos es fácil: se compilan en un archivo DLL al que hago referencia en los otros proyectos utilizando una referencia de proyecto. Pero, ¿cómo manejo archivos como JavaScript, hojas de estilo e imágenes? Estoy tratando de hacer esto "de la manera Visual Studio" para que sea tan fácil como sea posible de entender y depurar.

La configuración actual es algo como esto:

 
CommonControlsWebApp 
+- CustomControls 
+- resources 
    +- images 
    +- scripts 
    +- stylesheets 

WebApp1 
+- resources* 

WebApp2 
+- resources* 

WebApp3 
+- resources* 

*) directorio virtual en IIS.

El directorio virtual de cada aplicación web apunta al directorio de recursos en CommonControlsWebApp. Esto está configurado en IIS. Visual Studio no puede entender este enlace, por lo que la depuración me requiere adjuntarme al proceso IIS de forma manual.

Otra solución podría ser incluir cada recurso en el dll común usando WebResourceAttribute. Pero eso convertiría los enlaces src en algo así como WebResource.axd? D = GUID cuando veo el origen de mis páginas web, y me temo que esto hará que sea bastante confuso depurar.

Una tercera solución sería usar Subversion para incluir los mismos archivos en las tres soluciones. Nadie en el equipo ha intentado esto antes, por lo que no estamos seguros de qué tan bien funcionaría.

Siento que me falta una gran solución obvia sobre cómo configurar los proyectos. ¿Alguna sugerencia?

Answer 1

Muchos desarrolladores de control agrupan sus recursos web utilizando el segundo método que usted describe, agregándolos como recursos incrustados en el .dll. De esta forma, puede distribuir los controles sin tener que copiar un grupo de carpetas y archivos en cada sitio web que quiera usarlos, y asegurarse de que las rutas de las carpetas coincidan, etc. También obtiene la ventaja de una localización/internacionalización mucho más fácil de tus recursos

Sin embargo, la cosa WebResource.axd es un inconveniente. Por lo general, puede "depurar" las URL con algo parecido a Firebug para ver lo que realmente obtuvo de la solicitud, pero estoy de acuerdo, puede ser complicado si algo no funciona correctamente. Otro inconveniente es que si tiene docenas de recursos para un control de servidor, especialmente si se referencian varias veces cada uno (piense en una vista en árbol con cientos de imágenes pequeñas en los nodos), entonces la URL puede agregar una tonelada de bytes reales al final. Salida HTML

Si sus necesidades de distribución/localización superan sus necesidades de optimización/depuración, consideraría incorporar los recursos.

Si no, entonces definitivamente podría hacer # 3 - copiando todo en su sitio web usando Subversion. Consulte SVN Externals para saber cómo configurarlo. ¡Un poco de tiempo invertido en aprenderlo ahora puede ahorrarle toneladas en el futuro!

Answer 2

Tomé el camino más fácil y puse todos mis proyectos en una única solución. Luego creé un proyecto WebUserControlLibrary en el que coloque todos los controles compartidos.

Para conseguir que en el otro proyecto, a continuación, configurar el evento de construcción para cada proyecto para copiar el UCS en una carpeta especial:

copy "$(SolutionDir)WebUserControlLibrary\UserControls\*.ascx" 
    "$(ProjectDir)ImportedUserControls\UserControls" 

Y, por supuesto, hacen referencia al WebUserControlLibrary de los proyectos que lo necesiten.

ventajas de este enfoque:

• depuración en las obras de Visual Studio,
• No duplicación de código

Desventajas:

• solución Clunky :)
• Después de cambiar un archivo .ascx, el proyecto tiene para ser reconstruido Esto significa que no es posible cambiar el html y actualizar la página en IE y ver los resultados directamente.

Answer 3

que tienen un par de opciones para tirar en el cubo:

Opción 1: Usar un proyecto compartido para sus recursos: http://rion.io/2017/03/22/sharing-is-caring-using-shared-projects-in-asp-net/

Opciones 2 convertir su biblioteca de clases en un paquete NuGet. Creo que no hay que hacer mucho cuando el embalaje que no sea el siguiente para incluir todas las carpetas y archivos en el canto del directorio del proyecto NuGet:

c: \ nuget.exe empacar YOURPROJ.csproj -IncludeReferencedProjects prop Plataforma = AnyCPU -Exclude **. Tt -Exclude **. Txt