c# - español - Fusionando un proyecto común con variaciones de compilación en.NET MVC

mvc c#

Question

Tengo un sitio .net mvc que debería publicarse para muchos clientes diferentes y, por lo tanto, varía ligeramente según el objetivo.

¿Hay alguna manera de configurar la estructura central del proyecto, por ejemplo (simplificado):

• puntos de vista
• modelos
• controladores
• bienes
• compartimiento

y haga una fusión en el momento de la compilación con cualquier variación que pueda tener el objetivo actual. Por ejemplo:

proyecto central:

• puntos de vista
  • view1.cshtml
  • view2.cshtml

(eliminado el resto de las carpetas por brevedad)

cliente 1 objetivo:

• puntos de vista
  • view2.cshtml
  • view3.cshtml

resultado de fusión deseado:

• puntos de vista
  • view1.cshtml (del proyecto principal)
  • view2.cshtml (del objetivo del cliente 1)
  • view3.cshtml (del objetivo del cliente 1)

La misma regla debería aplicarse a los controladores, binarios, etc.

Answer 1

Hay algunas respuestas de código realmente buenas aquí, pero si desea un sistema de compilación automatizada para cada cliente y tiene muchas cargas, también podría ser una configuración muy difícil. Cuando podría configurar un script para Powershell que pueda hacer esto

pseudo codigo

For each client site
download base code to code/
download this client''s changes to code/ overwriting files
msbuild ....
copy client/ bin to build/client/
Delete code/
End For each

Answer 2

La respuesta a esta pregunta requiere alguna innovación. Así que mira mi solución por favor:

Configure la estructura central del proyecto para las clases que cubren los archivos de Modelo y Controlador y luego utilícelas con la técnica denominada Agregar elemento existente como un enlace que puede compartir lo siguiente:

• Lógica de aplicación común a ambas aplicaciones, pero no portátil
• Controles de usuario sin dependencias de plataforma

Lamentablemente eso no es compatible con vistas de navaja. Así que lo más fácil de copiar vistas compartidas es tener múltiples archivos de diseño como el famoso archivo _Layout.cshtml , uno en cada aplicación web. También puede compilar sus vistas de asp.net mvc Razor en una dll separada para usarlas como una referencia (como vistas compartidas).

Para los Activos , puede alojar todas sus hojas de estilo (y algunos javascript, si corresponde) desde su aplicación web principal y acceder desde cada aplicación web.

La carpeta bin tiene los archivos dll de MVC principales más los que agrega para usar en su proyecto y un archivo projectName.dll que se creará después de la construcción. Puede simplemente agregar / eliminarlos haciendo clic derecho en Referencias usando la herramienta Agregar referencia .

Answer 3

Lo primero que viene a la mente (y probablemente más fácil porque no requiere ninguna herramienta adicional) es crear un proyecto central con funcionalidad central, vistas y controladores. Y para cada cliente, cree un proyecto separado con vistas y controladores personalizados. Luego, para el proyecto específico del cliente, simplemente vincule todos los archivos requeridos del proyecto central. Puede ser un poco tedioso vincular los archivos según el número, pero parece factible.

Otro enfoque podría ser usar herramientas como CAKE o FAKE , con la ayuda de la cual puede crear un script de todo el proceso de construcción de la manera que desee, pero nunca intenté hacer tal script personalizado.

La tercera opción en la que puedo trabajar también es incluir condicionalmente los archivos según la constante definida, pero eso requerirá la edición de archivos * .csproj. El código puede ser algo como:

<Content Include="Views/View1.cshtml" />
<Content Include="Views/View2.cshtml" Condition="$(DefineConstants.Contains(''CORE''))" />
<Content Include="Views/View2.cshtml" Condition="$(DefineConstants.Contains(''CUSTOMER1''))" />
<Content Include="Views/View3.cshtml" Condition="$(DefineConstants.Contains(''CORE''))" />
<Content Include="Views/View3.cshtml" Condition="$(DefineConstants.Contains(''CUSTOMER1''))" />

Aunque no estoy seguro de lo fácil que será mantenerlo.

Probablemente consideraría dividir la aplicación en componentes / proyectos independientes que contendrán toda la funcionalidad relacionada con el componente. Durante la compilación, componga los componentes con FAKE en función de los componentes necesarios para cada cliente en particular.

Answer 4

Lo que necesita es una sección de superadministrador, donde podría [de] activar diferentes partes del sitio, dependiendo del cliente.

Answer 5

Su requisito es un gran candidato para una plantilla de proyecto de Visual Studio personalizada.

Estoy pensando en preparar un gran proyecto con todas las características que está implementando para cualquier cliente. Este proyecto también podría ser el tronco que podría actualizar cuando se necesite una nueva característica o una solución. Luego, exporte la solución troncal a una plantilla . Luego continúe con la plantilla de proyecto VSIX e incorpore un asistente en ella, para recopilar información del usuario sobre la creación de un proyecto. En función de la entrada, realice la acción adecuada y agregue / elimine los archivos necesarios o habilite / deshabilite las funciones según sea necesario.

O simplemente puede mantener los archivos de origen en el sistema de archivos y organizarlos en la plantilla sobre la marcha, es decir, como resultado de la entrada del usuario durante el asistente. Al final del asistente, la plantilla se implementa y ... voilá.

Answer 6

Yo usaría múltiples proyectos, nuget o el control de código fuente. Hablaré sobre estas ideas a continuación, pero sin ningún orden en particular. Al final puedo incluir una preferencia hacia uno u otro.

La primera idea de la que hablaré es usar múltiples proyectos. Crea tu proyecto base, llamémoslo WebBase. Crea tu sitio web central del que has hablado. A continuación, cree el sitio web del Cliente1, si crea el Cliente1 como un sitio vacío, tendrá que volver a crear las estructuras de carpetas en WebBase o puede crearlo de la misma manera que hizo con WebBase y eliminar todos los archivos (hágalo desde Visual Studio); de cualquier manera terminas con la estructura de carpetas sin archivos. Recomendaría mantener web.config, packages.config, carpeta de propiedades con AssemblyInfo.cs. Luego agregará los archivos de WebBase, pero no los agregue normalmente. Para el propósito de la ilustración, veamos la vista del índice de inicio: expanda la carpeta de vistas en Customer1, haga clic con el botón derecho en home, elija agregar, elija Exising Item, busque fuera de Customer1 y luego ingrese a WebBase / Views / Home y haga clic en index.cshtml, ahora ¿Notaste el desplegable en el botón? haga clic en eso y elija "Agregar como enlace". Ahora haz esto para todos los archivos en WebBase! Parecerá engorroso elegir "agregar como enlace" cada vez, pero si solo hace clic en agregar, copiará el archivo y las actualizaciones no se propagarán de WebBase a Customer1. Además, verá cosas como eliminar del proyecto frente a eliminar (con un aviso sobre la eliminación permanente).

El segundo pensamiento sería crear un paquete nuget para WebBase y puede instalarlo como un paquete, la ventaja de este enfoque sería la creación de versiones y no requeriría que actualice cada proyecto con cada pequeño cambio. Mantendría cada proyecto completamente aislado. Lo malo es que necesitarías actualizar cada proyecto individualmente para propagar los cambios a nivel mundial. Necesitaría aprender sobre el archivo nuspec de nuget y cómo incluir archivos y demás. No es tan malo, es solo XML. Pero puede indicar qué archivos incluir cuando se instala / actualiza el paquete.

Tercero, sería el control de código fuente. Sé que con git puede usar el submódulo para incluir un proyecto separado (incluso desde un repositorio externo). Lo que podría ser una opción, o simplemente podría crear una sucursal de WebBase, configurar WebBase y luego derivarla en el sitio web de cada Cliente. Así que cree una sucursal llamada Customer1, comience a agregar las cosas personalizadas del cliente. Cambia de nuevo a WebBase, crea una nueva sucursal llamada Customer2 ... estás listo para las carreras. Cambie de nuevo a WebBase, realice un cambio global y luego fusione estos cambios en las sucursales Customer1 y Customer2.

Bien, lo admitiré, probablemente iría con la tercera opción. Te da muchos beneficios con poco inconveniente. ¡Incluso te da la historia! Si no está utilizando actualmente el control de código fuente ... ¡debería hacerlo! Puede instalar git en su máquina y tener la capacidad de verificar el código localmente y no tiene que preocuparse por un repositorio externo (aunque le recomendaría que tenga uno ya que le brinda DR).

De cualquier manera, hay opciones disponibles. Pero nada como un solo proyecto con archivo configurable incluye.

¡Buena suerte!