Programate algo - Programming Blog/Blog de Programación

Spanish version / Versión en Español Usually, a .NET project consumes standard and third-party libraries from nuget.org . For context, NuGet is .NET's de facto package manager, like npm for Javascript, PyPI for Python, Maven for Java, Conan for C++, and so on. It's common practice for an organization to own a NuGet repository hosted in a binary hosting service such as Artifactory or Nexus . If the organization develops its own libraries, they will be hosted in that particular repository. This way, libraries can be used across different development teams inside the organization, and also beyond it if libraries are chosen to be made public. This is all well and good, but sometimes the hosting service goes down, or it is desirable to tinker with the libraries locally before deploying them. In scenarios like these, it's helpful to have an extra NuGet source that lives in the developer's machine and can be used when building and developing .NET applications. T...

Versión en inglés / English version Típicamente, un proyecto .NET consume bibliotecas estándar y de terceros a través de nuget.org . Contextualizando un poco, NuGet es el gestor de paquetes o ( package manager ) de facto del ecosistema .NET, como npm para Javascript, PyPI para Python, Maven para Java, Conan para C++, etcétera. Es una práctica bastante establecida que las organizaciones tengan un repositorio NuGet privado alojado en un servicio de hosting de binarios como Artifactory o Nexus . Si la organización desarrolla sus propias bibliotecas, las alojará en dicho repositorio. Así, podrán ser reusadas entre distintos equipos de desarrollo dentro de la organización, e incluso fuera de la misma si se opta por hacerlas públicas. Todo esto está muy bien, pero a veces el servicio de alojamiento de binarios se cae, o se desea modificar las bibliotecas localmente antes de desplegarlas. En escenarios así, resulta útil tener una fuente NuGet adicional alojada en la máquina de...

Spanish version / Versión en Español If any of you ever published a .NET project as a NuGet package and needed some custom scripting to run when the package was installed, this used to be possible using the install.ps1/uninstall.ps1 mechanism . However, support for this was dropped in Visual Studio 2017, which bundles NuGet 4.x. The Init.ps1 script is still supported, but it runs every time the solution is opened, which might not be appropiate for most use cases. Another problem with the new VS 2017 NuGet way of doing things is that the .nuspec file, which was used to define metadata and files to package, is now gone; metadata is now handled via the project's properties, in the new Packaging section: In turn, this information is saved in the .csproj project file: The problem with this is, how to define which files to package inside the resulting .nupkg file using only .csproj? There is an alternate approach to NuGet scripting which involves embedding MSBuild ...

Versión en inglés / English version Si alguna vez publicaron un proyecto .NET como paquete NuGet y necesitaron ejecutar scripting personalizado al instalar el paquete, eso era posible antes usando el mecanismo install.ps1/uninstall.ps1 . Sin embargo, el soporte para esto fue retirado en Visual Studio 2017, el cual incluye NuGet 4.x. El script Init.ps1 sigue siendo soportado, pero el mismo es invocado cada vez que se abre la solución, lo cual puede no ser apropiado para la mayoría de los casos de uso. Otro problema con el nuevo manejo de NuGet en Visual Studio 2017 es que el archivo .nuspec, que se usaba para definir metadata del paquete y archivos extra a empaquetar, ya no está; la metadata en VS 2017 ahora se maneja a través de las propiedades del proyecto, en su nueva sección Packaging: Una vez ingresada en las propiedades del proyecto, esta información es almacenada en el archivo .csproj: El problema con este nuevo enfoque es, ¿cómo definir qué archivos empaqueta...