Projects and Releases
  • 09 Aug 2022
  • 2 Minutes to read
  • Dark
  • PDF

Projects and Releases

  • Dark
  • PDF

Projects and Releases in ProGet let you track the open-source and third-party components (packages) that your organization uses, and help you identify issues like vulnerabilities, license violations, and missing packages.

Release Overview

Projects and Releases will be automatically created when you integrate ProGet into your CI/CD pipeline, but you can also create, edit, and delete projects and releases from the web UI or by using the SCA API.


A project represents an application, microservice, or other software component that is built using open-source or third-party software packages. Projects have a few basic fields, and contain any number of releases.

Field Description
Name This name is used when uploading/importing SBOM files to identify which project they belong to, and are also used when exporting SBOM files
Description Markdown-formatted text that will be displayed under the project, and exported with the SBOM file
URL This isn't displayed in the UI, but is exported with the SBOM
Type This isn't displayed in the UI, but is exported with the SBOM
Owner An email address to notify when issues are discovered

Generally speaking, projects should be used for deployable software, and not for libraries packages. For example, a NuGet or npm package will use dependencies to specify the packages that it requires. Those dependencies usually won't identify a precise version number, but will instead give a range of versions that are acceptable.

This means you generally can't know which specific versions of other library packages that a library package will use until you actually try to use it.


A release represents a specific version of an application, microservice, or other software component, and contains an inventory (list) of the names and specific versions of third-party and open-source components (packages) that were used to create that release.


When ProGet detects an issue with one of those packages, such as an unwanted license or a new vulnerability, then an issue will be created and the project owner will be notified. From there, the issue can be remediated or resolved.

See Release Analysis & Issues to learn more.


The "Packages" tab on the release overview page will show all of the packages that are contained in the release, as well as their licenses and vulnerabilities.

Packages can be added to a release by uploading a SBOM document to the release.

If you need to add, remove, or change packages to a release, you navigate to Edit Release > Edit Packages, and modify the package list provided. This should rarely be done as packages are intended to be automatically added during the build process. You can also delete packages from the Packages tab.

Status & Lifecycle

You can mark a release as "inactive", which means that it will no longer be analyzed or be displayed on the "Usage" tab of a package. Releases should be considered active if they are currently in development or production, and inactive if they've never been deployed or are no longer used.

Was this article helpful?