.NET: offline NuGet packages

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. This is where the concept of offline packages comes in.

Interacting with NuGet sources can be done in an operating system and IDE-independent way by perusing the dotnet cli. For starters, to list the currently existing sources, in a terminal, run:

dotnet nuget list source

This will print a list of the NuGet sources currently configured for the system, and their Enabled/Disabled status. An example of such output would be: 

Registered Sources:
  1.  nuget.org [Enabled]
      https://api.nuget.org/v3/index.json
  2.  Artifactory [Disabled]
      https://artifactory.organization.domain/artifactory/api/nuget/organization-nuget
  3.  Microsoft Visual Studio Offline Packages [Enabled]
      C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\
  4.  Artifactory-dev [Disabled]
      https://artifactory.organization.domain/artifactory/api/nuget/v3/organization-nuget-dev

In this example, there's nuget.org (source 1), two Artifactory sources from the organization (2 and 4), and an offline source that is typically created automatically by Visual Studio upon installation (source 3). That source is bound to a local directory (C:\Program Files\...) instead of a URL like the others, which is a distinctive characteristic of a local source.

If an offline source does not exist, it can easily be created manually.

dotnet nuget add source <path-to-local-dir> --name <source-name>

If the source exists but is disabled, it can easily be enabled.

dotnet nuget enable source <source-name>

Once the local source exists and is enabled, all that is left is to push packages to it. Doing so may require administrative privileges depending on the directory. For the previous example, since the directory is inside C:\Program Files (x86), pushing to it will require admin rights for a limited Windows user. The same may happen in Linux if the local directory is inside a directory owned by the root user. In these cases, in Windows, the push command will need to be executed inside a terminal with admin rights. In Linux systems, sudo might need to be used. With that consideration, the command for pushing a package to a local source is:

dotnet nuget push <library-name-with-version>.nupkg -s <source-name>

It's important to remember that .nupkg binaries are the format that will be pushed. These binaries usually include the version number in their name; keep in mind that both package name and version number are what identifies the exact version to use. Also, using semantic versioning for all version numbers is recommended.

That's it for today! Happy holidays!

Comments

Post a Comment

Popular posts from this blog

Upgrading Lodash from 3.x to 4.x

Spanish version / Versión en Español There are many breaking changes from version 3.x to 4.x; all changes are detailed in the Lodash changelog . There is also a list of deprecated functions , with a regex you can use to detect usages in your code. However, since it is not an exhaustive list, I will list the changes I encountered when performing my own migration, to help anyone undergoing the same process. Direct renames This section includes functions in which only the name changed, i.e. the arguments and return value are the same. 3.x 4.x contains includes first head rest tail invoke invokeMap padLeft padStart padRight padEnd Direct renames if not using thisArg This section includes functions in which the only change is dropping "thisArg". If you are not using it, you can just rename. If you are using thisArg in 3.x, it can be dropped if you are using iteratee to acce...
Keep reading

C++/CLI: Trigger events from C++ native code and handle them in Managed code, Part I

Spanish version / Versión en Español Imagine we want to trigger an event from a native class which has a C++/CLI wrapper as an interface to managed code (C#, VB.NET). And let's deal with the general case in which we desire to pass extra information along with the event, and said information is not inside a CLR basic type, that is one which both native and managed C++ understand (int, float, char, and so on). In the native class, declare, just for convenience, a pointer to function type: typedef <nativeReturnType> ( __stdcall * PFOnEventCallback )( <nativeParameters> ); Still in the native class, declare a field of the type declared in 1): PFOnEventCallback m_fireEvent; In the place in the native class where we want to trigger the event: if( m_fireEvent ) m_fireEvent( <nativeParameters> ); (This suggests you to initialize m_fireEvent to 0, or NULL if you prefer) Now we need a setter for m_...
Keep reading

Traduciendo un custom control de Windows Forms de VB.NET a C#

Versión en inglés / English version No es tan fácil como tirar el código en un traductor , copiar y pegar. Hay ciertos detalles a tener en cuenta, a saber: Una vez creado el nuevo proyecto C#, en vez de crear el .cs y el .Designer.cs a mano, es mejor hacer click derecho al proyecto->Add->User Control. De esta forma, el .cs y el .Designer.cs ya quedan vinculados. Antes de largarse a editar el .cs y el .Designer.cs, abrir el control en vista diseño. Abrir la ventana de Toolbox, agregar un control cualquiera (un Label, por ejemplo) y salvar. Esto generará el .resx del control. Hecho eso, se puede eliminar el control que habíamos agregado. Si el proyecto original usa recursos, o sea que también hay un .resx a nivel proyecto, hay que generar uno. Esto se hace yendo a las propiedades del proyecto, sección Resources. Lo único que veremos será un link que dirá "This project does not contain a default resources file. Click here to create one.". Click allí y listo....
Keep reading