Hello Steven, Try visiting this page in a browser: http://<ProGet hostname>/feeds/<feed name>/NuGet.Frameworks/4.7.0-rtm.5148 There should be an error message like this: The version number provided is invalid, but would be valid if this NuGet feed were migrated to SemVer2. You can migrate a legacy NuGet feed to SemVer2 by clicking the button at the top of the feed management page.

This error message is coming from the NuGet client, and it's regrading your server's SSL configuration. Unfortunately I don't have enough information about your server or network configuration to tell you how to begin troubleshooting, but if you search that error, you can find lots of tips on how to ensure you have certificates set-up properly, etc.

If the package does exist, and you can download the package from the ProGet UI, then it indicates that there is no problem with ProGet. The UI uses the same download URL, and whatever is shown in the UI will be shown in the API. To further troubleshoot, I recommend you to use Fiddler and trace the HTTP requests. You can also inspect the ProGet message center to see what error requests are being made tot the ProGet server.

Turns out I needed to migrate the feed to the "new format" that supports semver. Everything worked like a charm afterwards. Thanks

For the Windows service, the only requirements for the service account are (assuming default file system package store configuration) read/write access to the directory where the underlying packages are stored (default is in ProgramData), read/write access to the service installation directory (default is in Program Files), and granted access to the ProGet database role named ProGetUser_Role. For the web application (Windows service or IIS application pool identity), the requirements are the same as the Windows service, plus read/write access to the website installation directory. Note again that the Desktop Hub installation privileges is orthogonal to the account that ProGet runs as, since it would obviously require more privilege to create/update/grant in the database and also create subfolders in Program Files & %ProgramData%. As an extra word of caution, if D: is a mapped drive, be sure to use the full UNC path in configuration settings within ProGet.

Thanks for the clarification. Unfortunately I can't mention any commercial products because the site this will be published on requires that commercial products be sponsors of the site. Unless Inedo wants to be a sponsor for 4sysops ;-)

I see what you mean. Though in this video the suffix is used for dev versions or release candidates. But I guess we could (ab)use this for branches. Will try and see how it goes.

Thanks for the additional troubleshooting. I suspect this is due to the way we are migrating dates from the old table to the new. I've created an issue to track this here. (It may not be publicly accessible yet, it's a new project and the permissions may not have propagated)

Otter, BuildMaster, Hedgehog, and ProGet for Windows all require any supported version of Microsoft SQL Server. So, 2017 would be supported, since Microsoft supports it still. 2005, however, not.

Sadly, for me, the given DLL cannot just be dropped into the folder to replace the old DLL without producing a binding redirect error: [FileLoadException: Could not load file or assembly 'ProGetCoreEx, Version=5.1.3.10, Culture=neutral, PublicKeyToken=20535527eaf4e568' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)] Inedo.ProGet.WebApplication.<BeginFirstRequestAsync>d__2.MoveNext() +0 System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start(TStateMachine& stateMachine) +114 Inedo.ProGet.WebApplication.ProGetHttpModule.BeginFirstRequestAsync(HttpApplication app) +90 Inedo.Web.<HandleBeginFirstRequestInternal>d__28.MoveNext() +306 System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() +31 Inedo.Web.InedoHttpModule.ProcessEnd(IAsyncResult ar) +117 System.Web.AsyncEventExecutionStep.InvokeEndHandler(IAsyncResult ar) +219 System.Web.AsyncEventExecutionStep.OnAsyncEventCompletion(IAsyncResult ar) +159 System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() +31 System.Web.AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +611 System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) +213 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +131 ProGetCoreEx is version 5.1.3.9, however it expects 5.1.3.10

This will be fixed with PG-1313

Update: I've filed this bug with Docker: https://github.com/docker/distribution/issues/2649

It's fixed. Not only that, but listing the packages also seems faster. Thanks!

If you need to supply credentials when connecting to the domain, make sure "Specific list..." is selected, and enter it as: domain.local,CredentialName Where CredentialName is the name of set of Username & Password resource credentials created via Admin > Change User Directory > Advanced > AD Credentials > Create

Thanks for the quick update John. Definitely looking forward to the 5.1 release now, once it is out of Beta.

Ok, I use this KB 2 days ago and i added netbios name, fqdn but same problem. I try to change the user context but same pb. Error 503 - service unvailabable I will change my stack of web and i will go to install IIS...but is strange for an editor to indicate don't use "web integrade proget server" Thanks.

Copying from associated support ticket: It's not a bug per se, more of a design flaw with the introduction of external package stores. Basically, it checked to see if the package could be opened and if not, deleted it from the DB. However, there are many reasons a package might not be accessible (network down, invalid S3 credentials, disk inaccessible, S3 down, etc.), so this functionality was removed since then.

Good questions; You can configure ProGet to block packages with "unassessed" vulnerabilities; this is not the default configuration because a lot of times vulnerabilities are discovered after you've already been using a package anyways That's true, but maybe we could expand webhooks? I'm not sure, but it seems like it could be a feature request if it's something you'd actually want to use, etc.

The tracking issue for this is here: PG-1309