Any updates on this? I encounter the same issue and none of your comments helped .

This came in 5.2 -- http://inedo.com/proget/5.2

Hi Francois, The quickest way to get something like this implemented is by going through the feature request process this process really drives our roadmap. as for ETA, I wouldn't want to predict that, but we do release new versions on a frequent basis. Thanks, Jason

Hi Christopher, I am not able to recreate this issue locally, can you confirm that your license key is valid, current, and activated. It looks like you were issued a new license key last month 4/16/2019 for ProGet Basic. An invalid or expired key will force the retention policy to execute in dry-run mode so I want to rule that out first. Thanks, Jason

Hi Paraig, Replication between two different versions will likely work, though it would be a good idea to verify correctness when complete. We try to maintain backwards compatibility though we don't officially support this scenario (by this I mean we don't routinely test replication with older versions). In the event of a problem, another possibility is to replicate to another 4.6.7 instance, and then upgrade it to the latest version.

The error message you are getting (There must be exactly one package.) is essentially saying the file that you are trying to push doesn't exist. And since I can see that the file is created in the previous pack command, My thought is that file creation is not fully complete or the file is still in use by the pack command. I am thinking it might be useful to add a Start-Sleep -s 5 command between the pack and push commands.

This appears to be an issue with the TFS credentials provider - the 401 status code means credentials were not supplied (and the error message confirms that as well); but typically clients should followup with a 2nd request that includes credentials when the 401 is received. If credentials are actually sent and are invalid/forbidden, then a 403 would be returned by ProGet.

I would try to reboot the server; sometimes the windows service manager caches information that makes it hard to detect. Next, it could be that you don't have permission to view the service. You can use a tool like sc.exe to unregister the service. Then, it should work

I'm sorry for the difficulty; I can't say I've ever heard of "the server crashes and the only option to recover is to reinstall", but I'm thinking it's something unrelated. All that page does is change a setting in the database that instructs the connector code reads to determine how to configure the proxy. Instead of re-installing, can you investigate the windows event logs and see what errors are happening? Can you give more details about "only option to recover" means? I'm guessing the service crashes, but you can simply start up the service or reboot if that happens.

Didn't get the answer quite right the first time. The error occurs if the version is postfixed with som text. In my case, I postfixed the branch name to the version number - e.g. 1.0.0.0-master.

Yes. the latest version will work.

hi Charlie, Can you provide us with a very specific reproduction case? Here is a very specific case where it's working as expected... { "name": "dfhack-test-1", "version": "0.44.12-r2.p190516000", "contents": [ { "type": "virtualDirectory", "source": "dwarffortress/core/linux64:0.44.12" }, { "type": "virtualDirectory", "source": "dfhack/core/linux64:0.44.12-r2" }, { "type": "virtualDirectory", "virtualPath": "hack/plugins", "source": "dfhack/plugin/weblegends/linux64-pre:0.44.12-r2.p190516000" }, { "type": "virtualDirectory", "virtualPath": "hack/plugins", "source": "dfhack/plugin/df-ai/linux64-pre:0.44.12-r2.p190516000" } ] } You can see this package live at https://proget.lubar.me/feeds/DwarfFortress-prerelease/dfhack-test-1/0.44.12-r2.p190516000

Hi Sergey, It's not built in but you can integrate it with custom directories. Please see https://inedo.com/support/questions/3991 for a related discussion.

In what context would this protocol be used? My understanding is that BITS is used for background/asynchronous transfers, and in the common Otter use-case, the package needs to be available on the server in order to progress through a configuration plan, therefore the only benefit I can see is the network throttling.

Hi Anup, Here is some documentation regarding active directory configuration across all of the Inedo tools: Using LDAP & Active Directory

That's great! Thank you Jhon.

Thank you very much for your precision. I realy appreciate it. I personaly work with non conterize Postgres database in order to avoid data corruption issue; but I understand your make this decision. Hava a good day, Mathieu HOFERT

Hi Anderson , Of course, a lot of our customers host ProGet in the cloud, and just install it on their own server in the cloud. But, we found it wasn't so popular to pay us to do that. The pricing was basically hosting costs + license costs + overhead, so something like $150/mo, depending. We stopped offering it, because we found most customers were either looking for a cheap, multi-tenant service (like $20 to $50/mo), or for really advanced infrastructure far beyond our capabilities (like dozens of servers globally linked, at like $10k/mo+). We are planning to launch “bring your own license” VM/Container in the cloud services at some point, and may leverage that as a hosted option. Any datapoints or insights you might have are always welcome, and I’ll share those to our leadership!

Eventually, but we haven't had too many requests for it :) If this is something you're interested in, we'd love to partner with a customer or two to help get this developed.

ProGet is licensed per server, so you need a separate license per server. We do permit temporary using the same key in the case of moving servers, etc., but only if they're used in a temporary state and decommissioned soon.