inedo-engineer

Hi @steviecoaster ,

Offline / air-gapped installation is common and a documented use-case:
https://docs.inedo.com/docs/installation/windows/inedo-hub/offline

As the article mentions, you can download the "offline installer", which is essentially a
self-extracting zip file that runs a Custom Installer created using the Inedo Hub.

That .exe file is not suitable for automation, so if that's a requirement then you'll need to use an alternative if you wanted to automate upgrade/installation. That article outlines a few concepts, but ultimately it really depends how "air-gapped" we're talking here.

If we're talking a SCIF with "security-guard inspected installation media", then I don't think automation is really going to really get you much ;)

Thanks,
Alana

Hi @reseau_6272 ,

Just to confirm, you've switched the ProGet service from a domain account to use Network Service, and when starting the service you're getting some kind of permission error from SQL Server?

The easiest solution is to simply switch to using a username/password instead of Windows Integrated Authentication and edit the connection string appropriately. Keeping in mind that, eventually, you will need to move away from SQL Server and migrate to PostgreSQL, which will not have these issues.

Otherwise, you will explicitly need to grant a login to the machine account. Network Service is represented in SQL Server as the machine account (e.g., DOMAIN\MACHINENAME$), and the identity needs to be explicitly created CREATE LOGIN [MYDOMAIN\WEB01$] FROM WINDOWS; before you can assign permissions.

Thanks,
Alana

Hi @gbeckett,

Glad to hear it is working for you! Please let us know if you run into any other issues.

Thanks,
Rich

We've tracked this down to an issue with native symbol files indexed in a PostgreSQL database. It will be fixed by PG-3243 in ProGet 2025.24, scheduled for release tomorrow (20 March 2026).

Packages with affected symbol files should be re-uploaded to ProGet following this release to resolve the lookup issue.

Hi @koksime-yap_5909,

Good news, it's available now for testing! We're considering merging to ProGet 2025, or maybe keeping for ProGet 2026?

Anyway, I posted a lot more detail now:
https://forums.inedo.com/topic/5696/proget-is-unable-to-download-maven-packages-that-use-a-nonstandard-versioning-scheme/2

Thanks,
Alana

FYI -- locked this, in case anyone has comments/questions on that change, I guess that post will be the "official" thread at this point :)

Hi @it_9582 ,

Thanks for checking that! Well, I'm not sure then :)

From here, how about sending us the package? Then I can upload it and see about debugging in ProGet to find out where it's coming from.

If you can open a ticket and reference QA-3010 somewhere it'll link the issues right-up on our dashboard. Then you can attach the file to that ticket.

We'll respond on there, and eventually update this thread once we figure out the issue.

Thanks,
Alana

Hi @joshua-mitchell_8090 ,

Thanks for the inquiry! The changes are available in the inedo/proget:25.0.24-ci.4 container image, and we'd love to get a second set of eyes. Are you using Docker?

They're relatively simple, but we just avoid changing stuff like this in maintenance releases... so it's currently slated for ProGet 2026.

But it should be okay for a maintenance release. Please let us know, we'll decide to release based on your or other user feedback.

Here's what we changed.

First, we added a "sixth" component called IncrementalVersion2 that will support versions like 1.2.3.4-mybuild-678 (where 4 is the second incrementing version), so that vulnerability identification can work better. Our implementation is based on the the Maven version specs, which in retrospect, seems to be followed only by ProGet. Pretty low risk here.

Second, we changed our "path parsing" logic, which identifies the groupId, artifactId, version, artifactType from a string like /junit/junit/4.8.2/junit-4.8.2.jar into /mygroup/more-group/group-42/my-artifact/1.0-SNAPSHOT/maven-metadata.xml.

It's a little hard to explain, so I'll just share the new and old logic:

//OLD: if (urlPartsQ.TryPeek(out string? maybeVersion) && char.IsNumber(maybeVersion, 0))
if (urlPartsQ.TryPeek(out string? maybeVersion) && (
    char.IsNumber(maybeVersion, 0)
    || maybeVersion.EndsWith("-SNAPSHOT", StringComparison.OrdinalIgnoreCase)
    || (this.FileName is not null && !this.FileName.Equals("maven-metadata.xml", StringComparison.OrdinalIgnoreCase))
    ))
{
    this.Version = maybeVersion;
    urlPartsQ.Pop();
}

Long story short, this seems to work fine for v8.5.0 and shouldn't break unless someone is uploading improperly named artifact files (e.g. my-group/my-artifact/version-1000/maven-metadata.xml or e.g. my-photo/cool-snapshot/hello-kitty.jpg).

Thanks,
Alana

Hi @gbeckett,

I just pushed out a pre-release version of ProGet 2025.24-rc.3 and can be installed via InedoHub. Please see our our guide on installing pre-release verions for more information. Please let us know if you have nay problems.

Thanks,
Rich

Hi @koksime-yap_5909 ,

Just as a quick update! Given that this is a more wide-spread problem, we've fixed the code and plan to release in ProGet 2026 (or possibly sooner, if we can make it low-risk enough in a mainteannce release).

Thanks,
Alana

Hi @phil-sutherland,

Thanks for sending this over to us. This looks to be a regression in the PostgreSQL migration. I have created a ticket, PG-3241, to fix the issue. This will be fixed in the next maintenance release of ProGet 2025.24, due out on March 20, 2026.

Thanks,
Rich