Nuget: ¿almacenar packages en control de fuente o no?

Actualmente no usamos nuget para nuestras dependencies, prefiriendo ir a la vieja usanza y pegarlas todas en una carpeta de libs y hacer reference desde allí. Lo sé. Así que 1990's.

De todos modos, nuget siempre me ha hecho sentir un poco mareado … ya sabes, confiar en la nube y todo eso. Como tal, me encuentro principalmente de acuerdo con Mark Seeman (ver aquí: http://blog.ploeh.dk/2014/01/29/nuget-package-restre-considenetworking-harmful/ ) que dice:

Personalmente, siempre deshabilito la function y en su lugar verifico todos los packages en mis repositorys. Esto nunca me da ningún problema.

El problema es que esto ha cambiado en la versión 3, no puede almacenar packages junto con la solución, como se describe aquí: https://oren.codes/2016/02/08/project-json-all-the-things/ . Lo cual se estropea comprobándolos en el código fuente.

Entonces, ¿me estoy preocupando por nada aquí? ¿Debo beber bien del nuget, o estar del lado del señor Seeman y ser del tipo de precaución?

Almacenar packages NuGet en el control de código fuente es una idea realmente mala. Accidentalmente lo hice una vez y terminé hinchando mi código fuente considerablemente, y eso fue antes de .NET Core …

Bebe en profundidad del pozo NuGet. La mayoría de los componentes de software están empaquetados de manera similar en estos días (NPM, Bower, etc.). La publicación de blog a la que se hace reference tiene dos años y la administración de packages está cambiando rápidamente en el mundo de .NET, así que aquí tengo algo de mi experiencia últimamente.

  • Los packages NuGet no se pueden eliminar de nuget.org. Pueden estar ocultos, pero si su aplicación solicita un package oculto, lo downloadá de la forma habitual. Nunca desaparecerá en el vacío.
  • 'Habilitar restauración de packages' ya no es un problema porque ahora es una opción pnetworkingeterminada en NuGet 2.7+. Ya no tienes otra opción.
  • Los packages ya no se almacenan por solución, sino por máquina, lo que ahorrará una tonelada de ancho de banda y disminuirá el período de recuperación inicial al build.
  • Si construyes un nuevo proyecto usando .NET Core, tendrás docenas más packages ya que todo el BCL estará disponible como packages NuGet. ¿Realmente desea registrar todos los packages System. * En el código fuente?