asp.net-mvc - net - web forms c#

Classic ASP y MVC uno al lado del otro, ¿diferentes proyectos? (2)

Intenté preguntar esto de diferentes maneras, pero demos otra oportunidad (ya que todavía no he recibido una respuesta y esto me está volviendo loco).

Tengo una aplicación clásica ASP 3.0 muy grande (~ 350K líneas) que quiero comenzar a migrar a ASP.NET MVC. Me gustaría mantener los viejos archivos ASP en un proyecto separado del material de MVC.

Ideas sobre cómo depurar estos? ¿Debo simplemente volcar los archivos en la misma carpeta y crear dos proyectos diferentes (una aplicación WAP y una MVC) que hagan referencia a los archivos y carpetas relevantes requeridos por cada uno? Esto debería funcionar, pero ¿alguien tiene una mejor idea? Necesito la capacidad de migrar partes pequeñas de la aplicación individualmente, ya que probablemente demore uno o dos años en completarse.

Descargo de responsabilidad esto está fuera de mi cabeza, nunca he hecho esto y podría estar muy lejos de la realidad:

Después de la revisión inicial, creo que tiene 3 alternativas que se describen a continuación:

Fusionar en una aplicación,
Tener una aplicación como aplicación raíz y otra como aplicación "secundaria"
Copie la fusión en una aplicación después de la compilación (esto podría no ser posible)

1) Merge en 1 aplicación le brinda los siguientes beneficios, relativamente simple, necesita modificar el archivo global.asax - configurando sus rutas de mvc, IOC, etc. - HttpApplication, Session y Security (suponga que se basan en formularios) simplemente funcionará.

Hay un problema un tanto "menor" y que es compartir tempData, esto debería ser capaz de crear si puede instanciar un SessionStateTempDataProvider en su página (Init para cargar, descargar para guardar similar al estado de vista), no puedo encontrar el blog, pero creo que fue Steve Sanderson hace unos meses.

La cobertura de su unidad de prueba / código será difícil de rastrear y es posible que deba pensar en formas de gestionarla, lo cual es una discusión completamente diferente.

2) Con esta opción, tendrá una separación completa de las aplicaciones con un nuevo conjunto heredado de problemas. HttpApplication. * Podría causar un problema si sus aplicaciones lo utilizan, ya que harían referencia a diferentes carpetas, contextos, etc., pero ignorarán que está satisfecho de que sean aplicaciones diferentes.

El siguiente gran problema es hacer que Sessions funcione, ahora esto podría ser muy complicado, si la sesión está en proceso, entonces cada aplicación no verá las otras sesiones de aplicaciones, sin embargo, si está usando SQL o un servidor de caché personalizado para el estado de la sesión, debería estar capaz de "piratear" los procedimientos o las referencias / configuración y compartir el estado de la sesión entre las aplicaciones - en el peor de los casos tendrá que escribir su propio proveedor de sesión, (nunca he escrito uno así que no sé qué tan difícil será esto o si es incluso práctico).

El siguiente problema es la autenticación de formularios, puede hacer el inicio de sesión único estándar y asegurarse de que las claves de validación y descifrado de MachineKey sean las mismas en la configuración. Los datos de temperatura van a ser los mismos que la opción 1. Para mí, esto parece demasiadas cosas para cambiar, para ser viable ...

3) Suponiendo que tome su sitio asp.net y agregue una referencia a mvc y agregue su enrutamiento asa global predeterminado, etc., la aplicación debe seguir compilando limpiamente pero arrojando errores de enrutamiento al buscar rutas tipo / controlador / acción / id, por lo que es posible que deba verificar esto.

Suponiendo que funcione, podría "potencialmente" hacer una fusión xcopy de las dos aplicaciones (es decir, copiar todos los archivos de la aplicación mvc en la implementación previa de la aplicación asp.net). Sé que puedes hacer esto creando un gran proyecto con ambas aplicaciones ya fusionadas, pero de esta manera el código se combina en una etapa muy posterior en el proceso de compilación. (Las asambleas firmadas, vienen a la mente como problemáticas). Y una vez más, tendrá que trabajar en el problema de los datos temporales ...

No he tocado la reescritura de la url y muchos otros aspectos que debe tener en cuenta, y tenga en cuenta que existen distintas desventajas con cada enfoque que puede tener que considerar.

En resumen, creo que sus mayores problemas serán HttpApplication, Session y TempData desde el lado de mvc, ver el estado desde el lado de asp.net. Reescribiendo URL, la autenticación debería ser más fácil.

Y como dijo Forrest Gump: "Eso es lo que pienso".

Después de mucha investigación, descubrí que una buena manera de mantener estos proyectos fusionados desde el punto de vista de IIS, pero en proyectos separados en Visual Studio, es crear los proyectos en la misma carpeta, pero mantener los archivos para cada uno en sus propios archivos .csproj.

De esta forma, es posible publicarlos por separado o como una solución, y puedo ver fácilmente al analizar qué archivos pertenecen a cada proyecto. A medida que los elementos se trasladan de ASP clásico (otra vez, NO .NET) a MVC, cambio el nombre de las carpetas antiguas en el proyecto ASP de name a delete-me-name y creo un área correspondiente en el proyecto MVC.

Esto está funcionando bastante bien hasta ahora. El único otro cambio fue la adición de una regla de ignorar ruta en el archivo global.asx.cs para ignorar los archivos .asp:

routes.IgnoreRoute("{resource}.asp/{*pathInfo}");

Hasta ahora, todo parece estar funcionando bastante bien.