Thank you so much for your answer and the confirmation for a futur support of Black Duck. I will contact you once we are ready to work with you (ProGet solution is in planification and installation phasis here). Thanks.

Thanks Dean. The image is available now.

You shouldn't be receiving a "401" error from the public npmjs registry. If you are, my guess is that you have some sort of proxy or firewall selectively blocking outgoing access to certain queries to the registry. Once you resolve that, then p[roblem #2 will also be resolved.

yes, after subscribing to one of our vulnerability providers like Sona OSSIndex or Whitesource (more coming later).

Not really I'm afraid... "Pulling with dependencies" would require implementing every dependency resolution algorithm of every version of every client, including the non-deterministic dependency resolution used by the npm client, and then somehow letting you select the algorithm version and the additional contet required by the algorithm (such as .net framework target versinon).

Hello, these errors are quite erare, but it can happen in dealing with randomly disconnecting web clients. The easiest thing to do is to set automatic recovery on the service. You can do this on the "Recovery" tab. You could also upgrade to iIS, which mas more transparent crash recovery.

It shouldn't, and if you're using SSL then it's encrypted traffic and nothing can "capture" it between... but keep in mind that ProGet is really only providing the server-side API. If you write a script (or use a tool) that logs all API calls to ProGet, or logs the full call to nuget.exe, then whatever you log is going to be logged.

I've never seen this before, but it seems that Visual STudio is caching the result as to not hit the server. Maybe you can refresh or do a search from within Visual Studio to cause it to hit the server? Please share if you find the solution; you may be able to disable caching in VS, but I don't know how off hand.

There is no additional ProGet configuration. Do note that PowerShell packages are actually NuGet packages behind the scenes, so you can always construct them and inspect them to make sure the manifest is being generated correctly before it's pushed to ProGet. Howeveer, also note that ProGet support uses SemVer2, which is slightly different, so makes ure you are following conventions that are compatible with both.

Hello Lev, A possible reason this might be happening is if Apache is caching the 404 error returned by Docker when the client checks for an existing layer and then returning the cached error after the layer is uploaded and the blob URL becomes valid.

I see; my guess is that they have a custom-developed feed, and that feed is only supporting the limited/minimum number of queries required to get it working in the versions of Visual Studio of they support. In other words, it's not a proper feed. ProGet relies on a feed implementing the required API endpoints. In this case, your best bet will be to download the packages from the vendor, and then upload them into your ProGet repository.

It's obscured from view in the UI, but we must store the password so that it can be used for authentication. We may support a encrypted credential in the future, but if you have access to the ProGet server you will always be able to decrypt it.

Hello Chris, I don't think Bower feeds store anything on the filesystem (it's all in the database). I've filed PG-1256 to add support for Maven feeds being stored in package stores.

Hi, I'm afraid we don't have a step-by-step tutorial available at this time. It's enough of a challenge to always keep our tutorial screenshots up-to-date, let alone screenshots of Amazon's interface :( But if you get stuck, please let us know. It should be pretty straightfowrard and similar to a regular installation on a virutal machine,.

Haha, I missed it by one minor verison. :-D Sounds good. Thanks for the quick response. Means I get to test my scripted upgrade process. :-D Have a good one.

That's actually pretty awesome. that's exactly what I was sort of thinking of doing.

Thanks for letting us know. We are totally redoing our installer soon, so we will probably take care of it then! I think, generally, you might want to install SQL separately when going automated. When SQL fails to install, it's not so graceful, and it will be harder to tell what went wrong when diagnosing a failed ProGet installation

This is not supported at this time.

No special case. The link to the package statistic indicate 863 downloads and when we click on this link it show us only local package and note what is present in the cache. It's just disturbing. And the statitc on remote package are instrusting as local packages.