- 14 Jan 2022
- 6 Minutes to read
What is a "Package" In ProGet?
- Updated on 14 Jan 2022
- 6 Minutes to read
Packages in ProGet
A package is a file that contains other files.
Unlike packages on NuGet.org or other open-source sites (RubyGems, Chocolatey, etc.), ProGet packages are private to you, even if they originated from a third-party source.
The manifest file included in the package has the package name and version. It gives you context on who did what and when with the package, which simplifies two of the most stressful dev events: auditing and rollbacks. This is because packages can be:
- Repackaged to indicate that a package has been tested
- Promoted to indicate a change in quality or who may access it
- Blocked from ever entering ProGet (and your environments)
- Inspected for vulnerabilities using quality controls you define
Packages help you uniformly distribute your applications and components. They have become a unifying concept across DevOps toolchains because packages are built once and deployed consistently across environments. Because of this, you can be certain that what does to production is exactly what was tested.
Because ProGet is a self-managed package repository, every package you store in ProGet stays as private to your organization as you like. And unlike basic solutions like nuget.server, ProGet can support many hundreds of packages in a single instance, even in the free forever version. These packages can be cached copies of third-party open source packages or proprietary packages your team creates, and everything in between.
With ProGet, you get much more than just a place to store packages:
- Vulnerability Scanning
- License Detection
- Cloud storage
- And much more
The rest of this page explains more about what packages are, how to use them, and other commonly asked questions. Looking for a specific package type? Documentation for different package types can be found in the menu to your left under "Feeds Types & Third-Party Packages."
What's inside a package?
There's not a whole lot to a package: It's just a zip file containing the files you actually want to distribute, as well as a manifest file that describes the package itself (like who took some action on the package and when they did it). The specific layout of the zip file and manifest is referred to as a package format.
How is a package different from an artifact?
Artifacts can be any type of file (e.g., .jar., .war, .dll, .rpm, .zip, .jpg). Artifacts are just files; no manifest data is included. You may have the file that you need but not the context you may require.
Packages have a standards-defined format (e.g., NuGet, PyPi, etc.) and include not just the files but the metadata as well.
What package types does ProGet support?
In addition to the Universal Package type, ProGet supports a growing number of package types:
- Ruby Gems
- Visual Studio Extension (.vsix)
- Maven (Java)
- npm (Node.js)
- Chocolatey (Windows/Machine)
- Debian (apt)
- Helm (Kubernetes)
- PyPi (Python)
- RPM (yum)
- Docker (containers)
Not seeing the package type you want? We are always looking for input on other package and feed types to support.
Using Third-party/Open-source Packages
Many times, your development will draw on third-party/open-source packages, like NuGet or Chocolatey. To use these packages in ProGet, you'll first create a feed for that package type. Then add a connector to your ProGet feed and point ProGet at the correct URL. The feed will then populate with packages from the external source.
You can eliminate time wasted waiting for third-party packages to download by pulling a local copy of the package to ProGet. You can also cache packages and/or metadata to ensure the packages you need are available in ProGet when you need them.
Creating and Publishing Proprietary Packages
Many third-party package formats, like NuGet, can be created internally for proprietary use. Using a tool like BuildMaster, you can apply the rigorous testing of CI/CD as you create .nupkg packages for private use. Check out the extensive documentation available for more popular package types for instructions on creating proprietary packages.
Once you've created a package, there are four ways to publish it to ProGet for use:
- Upload from disk: uploads a pre-packaged package from disk
- Push with the Client Tool: uses the command-line tool, such as nuget.exe or npm.exe, to add a package to the local feed
- Pull from another feed: pulls a package from another feed of the same package type
- Bulk package import/file copy: imports multiple existing packages at once
For more specific instructions on how to add a package to a feed, while inside ProGet, click the 'Add Package' button in the ProGet feed for that package type.
If there is a third-party package format designed for your specific case, we recommend you use it. In many cases, however, universal packages provide the best combination of simplicity, utility, and extensibility.
Publishing Your Own Applications as Universal Packages
The Universal Package format is very simple and can be used to package applications and components built with any technology: ASP.NET websites, NodeJS applications, Windows services, plug-ins for your applications, system configuration scripts, and so on. It's designed for both general-purpose use and as a platform for creating a new proprietary package format. You can also extend a universal package's manifest file with additional metadata (and then search using that metadata).
There are a lot of free and open-source tool options to help you create and publish packages to ProGet, either from your workstation, a build server, or anywhere else.
You can use any of these tools or libraries:
- upack.exe Command-line Interface
- UPackLib.NET library
- Universal Package Explorer
- Inedo ProGet Jenkins Plugin
- Push to ProGet Visual Studio Extension
You can also upload hand-crafted package files to the ProGet the UI, or simply do a HTTP Post with your own tool/scripts using the Universal Feed API.
Identifying and Versioning Packages
One of the most important aspects of a package is that it is uniquely identifiable using a name and version. This simple, human-readable identification is what makes packages so easy to distribute and consume.
For example, "HDars-API 1.0.4" is version 1.0.4 of HDars-API, which is newer than "HDars-API 1.0.2," older than "HDars-API 1.3.0," and different than "HDars-Web 1.0.4." "HDars-API" by itself is fairly meaningless, because it could refer to any version of HDars-API.
Universal packages (as well as some third-party packages) use the SemVer specification to describe the version number.
Common Package Operations
To publish or upload a package to ProGet, follow these steps inside ProGet:
- Create a feed for that package type OR open the feed you want to upload the file to
- Next to the "Manage Feed" button on the right, click the ▼. The dropdown will display "Add Package."
- Select the upload method of your choice from the pop-up window.
To delete or remove a package to ProGet, follow these steps inside ProGet:
- Go to the Packages tab at the top ribbon.
- Click the red X on the right of the package you wish to delete.
- Select "Yes, Delete Package" from the pop-up window. This is a permanent action. Note: You can optionally delete all versions of the package, which deletes all versions of that package only within that feed. To delete a package that has been promoted between different feeds, repeat these steps.
"Unlist" reduces visibility in searched. Packages won't show up unless you enter the exact URL.
*Note: This is only supported in NuGet
Package promotion in ProGet lets you separate packages by quality. Promoting a package will leave the package in the source feed and duplicate it into the target feed. You can manually delete the "older" package later or configure retention rules to do it for you.
To promote a package to ProGet, follow these steps inside ProGet:
- Go to the package overview page for the package you wish to promote.
- Hovering over the ▼ by "Download Package," select "Promote Package" from the dropdown.
- Select the target feed from the dropdown.
See the Package promotion documentation for more details.