Mantenimiento de references para soluciones en subversión

Tengo una solución con tres proyectos dentro de ella. Todos estos proyectos están destinados a ser utilizados independientemente si así lo desean. Para dar una image clara, mis proyectos son los siguientes:

  • Proyecto de biblioteca de class "general" que contiene muchas classs abstractas básicas como "Persona" y algunas classs de Ayuda.

  • Proyecto de biblioteca de class "EmployeeManagement" que contiene classs como Employee: Person, EmployeeAddressList y otras cosas relacionadas con la administración de empleados.

  • Un proyecto de aplicación web que hace reference a los dos proyectos anteriores para actuar como una capa de presentación / formulario web. es decir, "editemployees.aspx.cs" para editar información de empleados existente, etc.


Todo está bien y bien, pero cuando hago muchos cambios y luego envío los tres proyectos a sus tres repositorys respectivos, mi compañero de trabajo extraerá todos mis cambios de los tres repositorys y luego abrirá la solución general. Todo está allí e intacto, pero el proyecto de aplicación web ya no reconoce las references a General y EmployeeManagement. Se enumeran en la carpeta de references, pero el código en sí no comstackrá, gritando todo tipo de locura roja subrayada. La solución más simple es eliminarlos de la carpeta de Referencias y luego volver a agregarlos, y al igual que la magia, todo vuelve a funcionar.

Las preguntas que tengo son:

  1. ¿Por qué pasó esto?
  2. ¿Qué estoy haciendo mal? (¿Tal vez el order de empujar a los repositorys o el order de su extracción está desactivado?)
  3. ¿Qué puedo hacer para evitar que esto suceda?

Gracias 🙂

Lo más probable es que su layout de directory sea diferente al de su compañero de trabajo.

Su proyecto parece pequeño para justificar su distribución en tres repositorys. Será mejor que se concentre en la architecture de su software que en complicar la vida con una infraestructura de proyectos sobnetworkingimensionada.

Por cierto. en svn nos comprometemos y actualizamos 🙂

Sin saber más, vería sus respectivos files .sln y .csproj o .vbproj, y me aseguraré de que la ruta relativa a los proyectos incluidos no se sobrescriba cada vez que uno de ustedes realice cambios.

Los siguientes son ejemplos de references de proyecto incluidas en sus files de solución / proyecto:

.sln

 Project("{6f8415d8-82c0-4e47-8ddd-f3962bb3b518}") = "QuickJoe.Awesome", "QuickJoe.Awesome\QuickJoe.Awesome.csproj", "{e623a940-79ba-4762-af02-84993a2b37b7}" EndProject Project("{6f8415d8-82c0-4e47-8ddd-f3962bb3b518}") = "QuickJoe", "..\qjs\QuickJoe\QuickJoe.csproj", "{6754372e-b253-41be-9b83-23cf8bea786f}" EndProject 

.csproj / .vbproj

 <ItemGroup> <ProjectReference Include="..\..\qjs\QuickJoe\QuickJoe.csproj"> <Project>{6754372e-b253-41be-9b83-23cf8bea786f}</Project> <Name>QuickJoe</Name> </ProjectReference> </ItemGroup> 

Otro buen consejo (si aún no lo hace) es excluir específicamente los files .user y .suo. En algunos casos, son activamente dañinos cuando se cargan en una estación de trabajo diferente.

Si está utilizando Visual Studio, considere colocar su solución en la parte superior del tree de carpetas y los proyectos que se encuentran debajo. Visual Studio debe hacer reference a los proyectos a través de $(SolutionDir) , una de sus variables internas. De lo contrario, edite la solución a mano y establezca las ubicaciones de la carpeta / proyecto en relación con $(SolutionDir) , y luego todo debería ser portátil, sin importar dónde se encuentre.