Referencias, dlls, Team Foundation Server TFS, Nuget

186 views
Skip to first unread message

Kiquenet

unread,
Nov 7, 2014, 11:27:22 AM11/7/14
to altnet-...@googlegroups.com

Hola,

 

Espero que no sea tonta la pregunta, pero me da curiosidad saber lo siguiente:

 

¿Qué buena práctica seguir con los ensamblados-dll's que se referencian desde proyectos en un contexto de trabajo con control de versiones (Team Foundation Server y muchos desarrolladores trabajando en el TeamProject)? Y además, con Nuget.

 

Esta es la situación actual:

 

Hay varios desarrolladores trabajando en el TFS 2008, con TeamProject.  Se tiene una carpeta sharedlibs en el Main del TeamProject, e incluida en el control de versiones. Los proyectos referencian a las dlls de esa carpeta.

 

Ahora, hay algunas soluciones que han incluido paquetes con Nuget.  Por defecto, NuGet descarga todos los paquetes en el directorio de la solución.  

Por tanto, tenemos carpetas packages por todo el TeamProject. Además, se han subido al TFS.


 No sé si será correcto, la idea sería que hubiera una carpeta sharedlibs\packages, y ahí incluir todos los packages Nuget utilizados, y los nuevos que vayan a utilizarse. Se incluiría en control de código f uente TFS.


La situación que se plantea es cómo tener la configuración del Visual Studio, para TODOS los desarrolladores (en cada equipo del mismo), para poder lograr algo así ? En definitiva, llegar a una buena práctica.


Saludos y muchas gracias.


http://joseoncode.com/2011/05/31/nuget-keep-your-package-folder-out-of-your-cvs/

Control de Versiones con TFS Parte 3 - Gestión de dependencias con NuGet.pdf

http://vsarbranchingguide.codeplex.com/downloads/get/885309

Oscar Zárate

unread,
Nov 7, 2014, 6:57:14 PM11/7/14
to altnet-...@googlegroups.com
Lo que estamos hacienda donde trabajo yo es crear nuestros propios Nuget Packages para las dlls que creamos nosotros o para las dlls de terceras partes que no tienen Nuget oficial (o el Nuget oficial es de una version mas nueva que la que necesitamos).
Dado que el Build Server no tiene accesso a Internet, creamos un servidor de Paquetes Nuget interno donde ponemos todos nuestros paquetes y una copia de los paquetes oficiales que queremos usar.
De esta forma tenemos todas las referencias en Paquetes Nuget.

Lo otro que hacemos en marcar las soluciones para que "restauren los paquetes cuando hacen el Build" esto te crea una carpeta con Nuget.exe y un par de otras cosas y de esa forma no tenes que incluir en Source Control ninguna dependencia.

Creo que estamos matando varios pajaros con la misma piedra :-) tenemos las referencias controladas, versions que queremos y "easy build"

Espero te sirva.

SaludOZ,

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a altnet-hispan...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/altnet-hispano.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

Ariel Piñeiro

unread,
Nov 11, 2014, 12:33:51 PM11/11/14
to altnet-...@googlegroups.com
Kique,
         es facil que todos los proyectos apunten a un packages global. Podés hacer algo cómo esto:


sharedlib\packages (o la que deseas) crear el archivo dentro llamado repositories.config con el siguiente contenido.
<?xml version="1.0" encoding="utf-8"?>
<repositories>
<repository path="..\proyecto\packages.config" />
</repositories>
Luego en cada proyecto en particular, dentro de .nuget\Nuget.Config (habilitalo en caso que la carpeta no exista.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositorypath" value="\sharedlib\packages" /> (o la ruta relativa)
</config>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
</configuration>

Saludos,
Ari.-

Carlos Admirador

unread,
May 18, 2021, 4:46:35 AMMay 18
to AltNet-Hispano
Oscar, lo sigues manteniendo igual?
Reply all
Reply to author
Forward
0 new messages