Ya busqué extensamente una solución, probé diferentes enfoques pero ninguno funcionó, por lo que estoy preguntando aquí.
Mi necesidad actual es tener repositorios Git separados, cada uno con un archivo de solución .Net con proyectos relacionados. Uno o más de esos repositorios contendrán solo bibliotecas de clases y necesito usar esas bibliotecas dentro de otras soluciones de repositorios.
Lo primero que hice fue usar submódulos de Git para evitar copiar y pegar feo y seguir teniendo el código fuente de las bibliotecas de clases disponibles al desarrollar las aplicaciones.
Entonces, mi intento fue incluir el submódulo, luego, en mi Solución actual, “agregue el proyecto existente” y cargue la (s) biblioteca (s) de clase deseada (s).
El gran problema que no he podido superar es la restauración del paquete Nuget. Los proyectos importados hacen referencia a las bibliotecas en “..\Packages*”, pero cuando se importan como submódulos, se ubican en una subcarpeta adicional, por lo que no pueden encontrar las dependencias requeridas:
- MySolution.sln
- Packages folder
- MyAppProject folder
- Submodule folder
-- EXPECTED packages folder for MyLibraryProject that I cannot generate
-- MyLibraryProject folder
Una solución que encontré y probé fue este pero tiene dos grandes problemas:
- Se supone que funciona usando la restauración del paquete MsBuild y no quiero usarlo en absoluto.
- Incluso intentar usar la restauración del paquete MsBuild no funcionó en absoluto, todavía tengo una sola carpeta de Paquetes en mi carpeta de solución actual. Tal vez hice algo mal, pero nuevamente, no quiero usar el enfoque de MsBuild.
Ahora realmente me gustaría saber si hay una manera limpia de resolver este problema, o si lo único que puedo hacer es dejar de tener el código fuente de las bibliotecas disponible en las soluciones de mi aplicación y publicar mis bibliotecas en una fuente y referencia NuGet privada. ellos desde allí.
Gracias.
Parece que su problema es que los proyectos del submódulo están en un nivel de directorio diferente al de la solución de su repositorio. Este es un problema común de Nuget porque se restaura en el nivel de la solución. Puede usar la secuencia de comandos de ruta de sugerencia de reparación aquí para reemplazar sus referencias con $(SolutionDir) y probablemente resolver el problema.
https://github.com/owen2/AutomaticPackageRestoreMigrationScript/blob/master/README.md#fixhintpathsps1
-
Veo que hay una secuencia de comandos powershell limpia que corrige las rutas indirectas para poder escribir eso. Evaluaré esta posible solución, gracias.
– Mateo Mosca
17 de abril de 2015 a las 7:35
-
Si bien esto es viable, todavía estamos en el proceso de toma de decisiones, aunque parece que usaremos Nuget para las dependencias internas en lugar de los submódulos de git, como sugirió @jon-skeet.
– Mateo Mosca
20 de junio de 2015 a las 8:11
-
Desafortunadamente, NuGet sobrescribe el
HintPathcuando actualiza un paquete, por lo que debe ejecutar el script nuevamente. Tal vez un gancho de confirmación previa de git sería conveniente aquí.– Johannes Egger
3 de marzo de 2016 a las 8:25
Puede resolver este problema cambiando ..\packages en todas partes en todos los archivos *.csproj para $(SolutionDir)\packages. Funciona bastante bien. Este script lo cubre:
find -name "*.csproj" | xargs sed -i 's/\.\.\\packages/$(SolutionDir)\\packages/g'
¿Ha considerado usar NuGet para MyLibraryProject en lugar de submódulos de git? Ejecute un servidor NuGet local, genere un paquete NuGet para la biblioteca y agregue una referencia a eso en su aplicación. Solo una opción…
– Jon Skeet
13 de abril de 2015 a las 6:18
Gracias por su sugerencia. De hecho, he considerado esta opción, pero estamos pensando en usar un servicio de CI en línea como AppHarbor y eso nos obligaría a usar también un servicio nuget público (de pago), como MyGet, para poder restaurar los paquetes desde el servidor CI, y nos gustaría evitar eso.
– Mateo Mosca
13 de abril de 2015 a las 7:32
Bueno. ¿Y tiene que tener los dos niveles de directorio para el proyecto de biblioteca? (¿Podría el directorio del submódulo ser simplemente el directorio del proyecto de la biblioteca?)
– Jon Skeet
13 de abril de 2015 a las 8:05
No estoy seguro de haber entendido correctamente lo que querías decir. Git fuerza al menos 1 nivel de subdirectorio para los submódulos, por lo que no puede simplemente colocar su submódulo en la raíz de su repositorio actual. Esto es suficiente para descartar la posición de los paquetes para el submódulo.
– Mateo Mosca
13 de abril de 2015 a las 8:43
Tal vez eche un vistazo a fsprojects.github.io/Paket/github-dependencies.html ?
– Kamil Baldyga
17 de abril de 2015 a las 11:49