This article is part of a series on Migrating from Artifactory to ProGet, also available as an eBook.

Just like Artifactory, ProGet allows you to manage files and packages, but handles them a little differently. ProGet uses a modern package management approach, compared to Artifactory’s older, outdated file-based system. 

If you’re used to handling files in Artifactory, ProGet’s modern approach might come off as unintuitive. It’s like moving from a typewriter to a word processor. Although a typewriter is simpler to use, a word processor offers modern advantages such as spell check and formatting.

In this article, we’ll look at how ProGet handles files and packages compared to Artifactory. This will help you adapt to its “Package mindset”, and take advantage of its modern features.

Artifactory: Designed for Files 

Artifactory was launched nearly twenty years ago as a kind of “Maven2 proxy repository with advanced features”. Despite changes and new features over the years, at its core it’s still just a Maven repository acting as a file server. This is somewhat of an outdated solution by today’s standard, designed for Java-based projects and used by Maven build tool. It basically consists of folders that are considered “builds”, with a “POM” file that contains the build’s metadata. 

This file-based design is apparent throughout the product and user experience. Files in folders can be added or deleted freely, just like on a share drive. They are also organized just like a file server, meaning there aren’t any limits on what files you can put in what repository. You could easily take pictures of cat memes, for example, and upload them to a NuGet repository! 

Jokes aside, in practice Visual Studio will expect NuGet packages in NuGet repositories, npm will expect npm packages, and so on.  It may seem convenient to put any file you want in there at first, but it going to cause headaches in the long run. 

There were “benefits” to this back when release teams would want to “trim builds” to deploy fewer files later. It also saved on disk space, upload speed and bandwidth. This was a bigger deal 20 years ago when storage was way more expensive. These days it doesn’t make as much sense, with even high-quality storage being quite affordable. 

Artifactory also uses file SHA-1 checksums as the file names, in folders named after the first two digits of checksum. This makes it pretty difficult to tell which folders and files correspond to which artifacts in your instance. 

ProGet: Designed for Packages 

In contrast, ProGet 1.0 was launched as a “NuGet package repository.” Just like Artifactory, it’s seen many changes and new features, but it’s still mainly focused around packages stored in feed sources. Packages are single files, usually zip files with special extensions that contain other files and a manifest file containing metadata. These follow strict formats and specifications, based on existing standards such as those set for NuGet packages. Packages provide built-in support for versioning and dependency management, and integrate with CI/CD pipelines. 

Unlike Artifactory, ProGet stores its files in folders “as is”. It uses easily recognizable folder and file names, making it easier to identify files compared to Artifactory’s naming conventions. This is especially helpful in the event of disaster recovery or creating a backup.

ProGet’s package-based design means that you may not have quite the flexibility of files like in Artifactory, such as being able to put an npm package in a NuGet feed. However, ProGet has a feature called Asset Directories. These are similar to “Generic Repositories” in Artifactory. They have no relation to packages and just store files, letting you upload any kind of file you want. 

In ProGet you can also create Maven feeds. These are similar to asset directories, but serve as ProGet feeds that enforce Maven2 standards. These are a great solution when you have repositories with various files in Artifactory that you want to easily migrate to ProGet. 

Migrating from an Artifact to Package Mindset 

If you’re already using packages like npm or NuGet in Artifactory, ProGet can migrate these repositories easily. The same goes for using Maven, as long as you’re sticking to the Maven2 standards. However, you may find that ancient repositories (we’re talking 10+ years old) might have invalid/corrupt data that can’t be migrated. 

On the other hand, if you’re storing random files in your repositories, you’ll need another solution if you want to migrate these to ProGet. In this case, You can easily use asset directories instead. 

For your build artifacts in Artifactory, you can use Maven feeds like you technically are in Artifactory. For a much better solution though, you can use Universal Packages uploaded to a Universal Package feed. 

The Package Mindset with ProGet 

ProGet manages files and packages like Artifactory, but uses a different approach. While Artifactory uses an older, outdated Maven-based file server, ProGet uses a modern package-based system that supports versioning and dependency management. 

Migrating from Artifactory’s file-based approach to ProGet’s package system may feel unfamiliar, but ProGet’s approach offers modern advantages such as metadata handling and CI/CD pipeline integration. 

This article is part of our eBook on Migrating from Artifactory to ProGet, walking you through everything from setting up repositories to managing your vulnerabilities, licenses and much more. Download your free copy of “Migrating from Artifactory to ProGet” today!