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.

I did try that and it works outside Docker where it just uses the user that is running it. Within Docker though I can't get it to work. I tried giving it creds or api key and it just won't validate. On proget it never shows an attempt when it's the api key either. Anyway, this work around is working so now i'm progressing. I'll pass on the details once I have it working. Thanks.

I'm afraid you are simply producing invalid packages. Per the NuGet specification, a package id "may not contain spaces or characters that are not valid for a URL" ProGet could validate better on upload, but ultimately you need to stop producing invalid packages if you want to use them in TFS, VS, etc. Even if ProGet supported invalid packages, it's highly likely that those tools won't, and will stop working all of a sudden.

Licenses are activated against a particular machine, but they are not attached to that machine. If you transfer the license in the manner you describe (install on new server, uninstall on old server), then it's in compliance.

In order to prevent inclusion of prohibited licences, you will need to have all dependencies pulled through ProGet feeds to prevent them being downloaded in the first place. This also serves as a quality gateway, to ensure low-quality packages/components aren't introduced into your projects. You can enforce this at the build server (for example, with BuildMaster): simply have your build server always use ProGet as the only dependencies source, and this way if developers try to bypass ProGet, it simply won't build.

Thanks very much, Scott. You helped me by mentioning that the feeds themselves also need to support SemVer 2.0. I wasn't aware of that fact. So I just migrated our feeds an now everything works fine.