¿Qué archivos de proyecto ASP.NET MVC deben guardarse en un repositorio?

Question

background: Mis compañeros de trabajo y yo estamos trabajando en el proyecto asp.net mvc ... tenemos una computadora que funciona como servidor, donde se almacenará el proyecto ... cada uno de nosotros tiene una copia del proyecto y tenemos tortuga cvs configurado.

preguntas: cuando quiere confirmar algo, ¿qué archivos es exactamente lo que confirma? ... asp.net informa de muchos archivos dll, csproj, cs y sln que parecen ser diferentes de los del servidor.

Tal vez mi pregunta no es la correcta que debería hacer, por lo que agradecería alguna información sobre cuál es el mejor enfoque para trabajar en grupos.

Answer 1

El archivo básico csproj debe comprometerse cada vez que se agrega o quita cosas del proyecto, para asegurar que el proyecto cuenta con todos los archivos correctos. La solución (sln) es buena para comprometer, por la misma razón, aunque también la he visto sin ella. También querrás enviar cualquier archivo cs, naturalmente, ya que son el foco principal de las cosas.

Los archivos DLL solo deben comprometerse si son referencias externas. Se pueden ignorar las dlls internas de su proyecto, ya que las compilará cada computadora. También quiere evitar los archivos .user como innecesarios. Ignore las carpetas 'bin' y 'obj' para cada directorio, cuando se trata de confirmaciones también.

Answer 2

No debería verificar nada que el proyecto pueda generar. Por lo tanto, no es necesario verificar las carpetas bin u obj ni nada de eso, también quiere ignorar los archivos de preferencias del usuario.

Esto incluye dlls, a menos que sean dlls de terceros, luego debe verificarlos para asegurarse de que todos trabajen contra la misma versión y de esta manera no tenga que seguir cambiando las rutas de referencia.

Answer 3

Mantenemos todo excepto las carpetas BIN/OBJ en SVN. Tenemos todas las bibliotecas de terceros en una carpeta separada a la que se hace referencia.

Bondad,

Dan

Answer 4

No trabajo en asp.net, entonces responderé genéricamente. Tenemos un repositorio de código de subversión para nuestro sistema de versión, cvs también funciona bien. Los desarrolladores recuperan todos los códigos actualizados del repositorio, trabajan, se aseguran de que funcionen correctamente, realizan otra obtención, vuelven a compilar, prueban y luego confirman los cambios del código fuente en el repositorio. De manera regular, puede tener una herramienta o crear manualmente la aplicación desde el repositorio e implementarla en un servidor de prueba. Ningún código compilado debe colocarse en el repositorio.

-Jay

Answer 5

se utiliza la siguiente estructura del proyecto en el SVN (pero esto se aplica a CVS también).

+ tags 
+ branches 
> trunk 
    + build (build scripts) 
    + lib (external libraries) 
    > src (source code)  
    >> Organization.App (solution name) 
    >> Organization.App.Core (code library) 
     + Config 
     > Domain 
      > Model 
      > Persistence 
      > Queries 
      > Services 
     > Persistence 
     > Services 
    >> Organization.App.Web (mvc web app) 
     > Assets 
      + Images 
      + Scripts 
      + Stylesheets 
     + Controllers 
     + Views 
     + ViewModels 

Ponemos todas nuestras dependencias de terceros en la carpeta lib. Incluyendo MVC, que puede ser implementado bin. See this article by Phil Haack. Entonces, cuando un nuevo desarrollador se conecta, todo lo que tiene que hacer es verificar el tronco, y deben tener todo lo que necesitan para comenzar. El uso de un servidor de CI es fácil porque todas las dependencias de los proyectos están encapsuladas por la carpeta lib y todos los proyectos de visual visual hacen referencia a esos dll en esa carpeta lib.

¿Tiene sentido?

No importa la carpeta del núcleo y la carpeta web. Así es como estructuramos nuestros proyectos dentro de la solución. Pero eso es un whole other conversation. :)

Answer 6

Si está utilizando una herramienta de gestión de cambios de base de datos, como Tarantino, entonces también querrá comprobar las secuencias de comandos SQL Change y/o rellenar las secuencias de comandos. Tenemos una carpeta en nuestra solución 'Core' donde guardamos esto, es decir, 'Core/Database/Updates'. Usamos SQL Compare para encontrar cambios en nuestra base de datos luego verificamos esos scripts de cambio SQL para que otros desarrolladores puedan ejecutarlos localmente. Tenemos una configuración de tarea nant para llamar a Tarantino a sincronizar los otros entornos de compilación (Dev, QA) y ejecutar cualquier nueva secuencia de comandos de cambio.