asp.net - tutorial - visual studio code asp classic
Intranet ASP clásica y nuevas aplicaciones ASP.NET (4)
¿No puedes ejecutar el sitio asp.net como un directorio virtual?
www.site.com/dotnetapp/
Donde dotnetapp es un directorio virtual completamente separado?
Tenemos una intranet clásica ASP existente que consta de cientos de páginas. Su estructura de directorios se ve así ...
/root
app_1
app_2
...
img
js
style
Obviamente, app_1 y demás tienen mejores nombres en la estructura de directorios real.
Aunque las muchas aplicaciones tienen un comportamiento diferente, todas son parte de la misma intranet y, por lo tanto, comparten una apariencia común incluyendo hojas de estilo vía / estilo, imágenes vía / img y script de cliente a través de / js.
El problema (al menos para mí) se produce cuando quiero agregar una aplicación de intranet en ASP.NET.
En definitiva, me gustaría esta estructura:
/root
app_1
app_2
dotnetapp_1
dotnetapp_2
...
img
js
style
Me parece que a las "aplicaciones" de ASP.NET les gusta pensar que están separadas de todo lo que les rodea (esta puede ser solo mi comprensión de cómo son). Usted crea un nuevo "proyecto" en Visual Studio y es como si tuviera un nuevo "raíz" un nivel por debajo de la raíz real que quiero usar. Es como si esta nueva aplicación fuera una cosa, solo, con sus propias imágenes y estilo y otras cosas. Sin embargo, quiero que sea una parte secundaria de la intranet existente.
En última instancia, quiero poder hacer que mi intranet clásica de ASP sea la "raíz" y tenga "subaplicaciones" de ASP.NET que aún puedan acceder a / style y / img y, supongo que para ASP.NET tendré / masterpages .
Lo he intentado antes, pero creo que VS se atragantó con el par de cientos de páginas ASP clásicas que agregó al "proyecto" cuando hice que mi directorio raíz de la intranet existente fuera el raíz del proyecto ASP.NET (a través de Archivo-> Abrir-> Sitio web). Sería bueno editar mi intranet ASP clásica existente usando VS 2008 SP1 (actualmente uso el excelente Notepad ++ ) porque me gustaría tener más manos en VS pero supongo que esto no es absolutamente necesario.
También traté de tratar cada nueva aplicación ASP.NET como una aplicación por derecho propio, haciendo que el directorio / dotnetapp_1 sea la "raíz" de la aplicación (de nuevo, a través de Archivo-> Abrir-> Sitio web en VS2008). Sin embargo, VS luego se quejó cuando intenté hacer referencia / páginas maestras porque "pertenecía a otra aplicación". Creo que lo evité agregando un directorio virtual dentro de cada directorio de ASP.NET que "apuntaba" a la raíz / páginas maestras, pero no estoy seguro de que VS haya podido proporcionar felizmente la edición WYSIWYG cuando hice esto, en lugar de hacer una copia de la página maestra en cada aplicación ASP.NET que agrego a la intranet.
También es bastante probable que visite el framework .NET MVC, así que por favor ofrezca cualquier respuesta con ese marco en mente. Espero que los "proyectos" no sean tan importantes con MVC y que sean solo un grupo de archivos los que creen una aplicación que contribuya al todo (que es la intranet).
Entonces, la pregunta es: ¿cómo puedo agregar mejor las aplicaciones ASP.NET a una intranet clásica ASP existente (no me preocupan los aspectos técnicos de la sesión compartida entre ASP clásico y ASP.NET, solo el diseño estructural de los directorios y proyectos) y ser capaz de editar estas aplicaciones por separado en Visual Studio 2008 SP1 y aún tener estas aplicaciones "relacionadas" entre sí por una apariencia y sensación de intranet comunes *?
- Por favor, no solo publique la respuesta "use MasterPages". Aprecio que las páginas maestras sean el método de .NET para compartir estilos (y más probablemente) entre páginas relacionadas en la misma aplicación. Lo entiendo. Lo que estoy buscando es el mejor método para agregar aplicaciones ASP.NET a la intranet existente tan suavemente como pueda, lo que simplifica la edición de cada aplicación y donde cada aplicación puede compartir (si es posible) un estilo común de intranet.
Dado que ASP.NET es ahora la plataforma de desarrollo web estándar de Microsoft, es mejor que comience con un nuevo sitio web ASP.NET e importe sus páginas ASP y carpetas existentes en él. Una vez que tenga esa configuración y ejecución, agregar nuevas funcionalidades en ASP.NET será muy fácil.
Microsoft entendió que algunos clientes mezclarían ASP clásico y ASP.NET por un tiempo, y se adaptaron a esta necesidad haciendo que las páginas ASP clásicas funcionen dentro de un sitio ASP.NET. Lo que estás tratando de hacer es lo opuesto a esto (conseguir que ASP.NET funcione en ASP, por así decirlo), y ya estás teniendo dificultades.
Una solución sería usar el Administrador de IIS para configurar el sitio web (creado para su aplicación ASP.NET por Visual Studio) y agregar un directorio virtual para cada una de las carpetas comunes para que (por la naturaleza ''virtual'' del directorio virtual) ''aparecerá'' en la misma carpeta raíz que su aplicación ASP.NET.
/root
app_1
app_2
dotnetapp_1
<virtual>img
<virtual>js
...
img
js
style
Probablemente pueda crear scripts de IIS o editar un archivo XML si necesita hacer esto a granel, y estoy seguro de que debe haber una manera aún más elegante de hacer algo similar que no requiera mucho trabajo con el mouse.
Un par de formas diferentes de hacer esto:
- Si su estructura de carpetas listadas es la estructura de carpetas web deseada, entonces cualquiera de sus aplicaciones ASP.NET simplemente puede hacer referencia a /root/js/whatever.js o ../js/whatever.js y llegará a las carpetas que ya tiene. tener en la raíz. Esta es una alternativa a la solución de directorios virtuales ya mencionada. Esta es una solución bastante desordenada, que algunos de los proyectos que heredé en mi trabajo actual lo hacen.
- En un trabajo anterior, administré una aplicación híbrida Classic ASP / ASP.NET durante un par de años y lo hice haciendo una aplicación web ASP.NET en la raíz y moviendo todas mis páginas ASP en ella. Cualquier "subaplicación" que desee hacer debe ser solo carpetas en este único proyecto. [Sin embargo, las páginas ASP ya no tienen código de color en VS2008, lo cual era realmente molesto].