Hello Ali, The agent version is not shown in BuildMaster 5.x's server overview page, but you can view it by going to /administration/service-status and forcing a run of the AgentUpdater executer and then checking the log for something like Connected to localhost:46336 (v39.0.0.2); checking status... (in this case, the agent on localhost is v39.0.0.2, the version of InedoAgent distributed with BuildMaster 5.8.3)

If you want developers to always be able to use any version of a package, then you should configure a connector to that remote resource. Then, they will always be able to download the latest version of the packages they need, and ProGet will cache those packages.

There was a UI change; these are listed under "Containers" in the top UI.

Hello Antoine and Anton, I've filed this as PG-1376.

Just to be clear... you can't go from Windows >> Linux, because it's PostgreSQL vs SQL SErver. But if you're already on Linux edition, you can just upgrade the container; the database files and package stores are already configured to point outside the container.

We take problems very seriously, but we need to prioritize where to spend engineering resources tracking down problems. This was a edge case that we could not reproduce, and had a very minor impact, and only affected a very small number of free users with a very specific configuration; a free user was able to track down the underlying cause and we fixed it.

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 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)

Please check out the ProGet 5.0 Upgrade Notes -- it's got everything in there we're aware of, but please special attention to the bit about NuGet legacy feeds, since there were a lot of questions about it that could have been answered from reading that document.

Hi, Please refer the below blog. You may have an idea on Semantic Versioning. https://www.meritedin.com/robust-api.html Please don't forget to take a look on the videos listed on their playlist.

ProGet supports overwriting existing packages, provided the user has such a permission.

Excellent. Thanks for letting me know, Alana.

It looks like this was caused by a packaging issue with installation; this impacts some upgrades and certain Linux-based querying from the web app (i.e. if you just save, and don't validate, it should work).. You can manually fix by going to the BuildMaster installation directory and: Delete the libssh2.dll file from the Web\bin directory Copy the Service\lib directory to the Web\bin directory (so Web\bin also contains the lib directory) We will of course get an updated installer built as well, but this should get things working for you until then.

Please note the privilege changes in v4: Upgrade Notes for ProGet 4.0

Hi Luke, you'll want to put the connection string in quotes: bmdbupdate UPDATE /conn="Data Source=DB1;Initial Catalog=ProGet;Integrated Security=SSPI;User ID=Account;Password=Password;" We'll try to add that to a new version of the database updater! Cheers!

Nevermind, apparently, the installation was messed up because of the failed previous upgrades (due to the antivirus). The program was not registered anymore so the installer didn't detect it for upgrade. I simply installed over the previous installation and it worked! Now running on 4.0.9! Thanks a lot for the info and help!

Hi TJ, That upgrade path is fine, and quite common; as long as the shared storage is the same (I assume it's already a UNC path), then when you start everything up again (webserver, indexing service), it should be the same. There isn't so much risk going from 3.5 -> 4.0, but please do read the ProGet upgrade notes just to see what's coming. Just make sure to do a quick test on the current (2005/single server) set up as 4.0 before moving that to new servers. You can always rollback if there is a realy big issue (though, we haven't seen any yet!) Best, Alana

A "legacy" NuGet feed is a single folder; it's possible it's a different location than \Packages\Default if you configured it later.

There weren't any major, systematic changes that would have caused this to occur. Most likely ,the service isn't running, etc... I would roll back to the old version, then try to do the upgrade again.

Thanks Alana, I will have to run the install as a service account to make sure it has access to SQL. I didn't expect it connects to SQL server as it unpacks the resources. So, it didn't cross my mind that this would be an issue. I have not yet validated if the issue is resolved, but I am 99% sure it will be. I will reply to the post once I confirm it.