Yes, it solved the issue. thank you.

@gdivis said in ProGet 5.2.13 breaks Symbol Server / PDB download: It looks like this was caused by a change in our internal deployment process. I've logged this as PG-1615, and it will be fixed in ProGet 5.2.14, which is scheduled for release on Friday (October 18). Thanks for the report! Thank you very much for the quick fix!

@gdivis Awesome! Thanks!

Okay thanks for the fast answer

Hi; that message is coming from the operating system and ProGet does not have any sort of limit (we have customers with terrabytes of packages); perhaps you've configured it to a different drive, or something. I'd check there :)

Hello; for this, or really any other Dockerized web application, you can setup a reverse proxy. There are a ton of ways to do this, but I'd suggest to search for "How to Configure a Nginx as a HTTPS Reverse Proxy" and see which option(s) make sense for your environment

This would be captured in an event (Admin > ProGet Event Log); the UI doesn't currently support package-level queries (you can filter a few other ways), but you could do a database query pretty easily... SELECT * FROM [EventOccurrences] WHERE [Event_Code] = 'PKGADD' AND [Feed_Id] = 2 AND [Details_Xml].value('(/Details/@Package_Name)[1]', 'varchar(max)') LIKE 'Carbon' AND [Details_Xml].value('(/Details/@Package_Version)[1]', 'varchar(max)') LIKE '2.9.0'

No problem! That worked. Thanks.

I'll start with the easy one; connectors are "read only", there is no mechanism to push a package to a connector in ProGet. As for authentication, I really don't know. That's weird, and it's definitely nothing in ProGet. The 401 could be coming from a proxy server (inside your network) or from registry.npmjs.org itself, and there's no way to know within ProGet which it is. I can't imagine it's a proxy server that somehow works with a npmjs.org username/password. But, maybe it is. I don't know why registry.nmpjs.org would send you a 401. Other users haven't experienced this, and I just tested it on a brand new instance myself... and the connector worked just fine. There is talk of throttling large organizations, so maybe it's related to them blocking your IP or something? It could have also just been a temporary glitch, somewere. Maybe if you remove authentication, it will work. ABout the only way to diagnose this would be to attach ProGet to a tool like Fiddler or WireShark, so you can see the requests PRoGet makes, then reproduce those exact same requests, and either reach out to your internal IT folks or try your luck with npmjs.

Hello; Your best metric is going to be your users; if they're complaining it's slow, then it's probably too slow. My guess is that it's intermittant (during peak times). But in any case, it's not about the number of packages (a micro server can easily serve millions of packages nearly instantly), it's about the number of simultaneous connections (requests) to the server, and the features you've enabled (like license checking, etc). It sounds like you've got a single "2 core instance with 8gb of ram" server; while you can try to increase the hardware, the bottleneck is most likely network related; a single server might not just be enough to keep up with the traffic from your developers. Keep in mind that "plain old NPM" (i.e. registry.npmjs.org) runs on a massive, dedicated data center and is heavily cached (basically read-only). The ProGet Free to ProGet Enterprise article contains some general guidance that might help answer your questions: High Performance: 1 Server per 50 Developers. The network never slows down, never crashes. Average Performance: 1 Server per 100 Developers. The network slows down and drops productivity 10% on average during peak times daily. Acceptable Performance: 1 Server per 200 Developers. The network slows down and drops productivity 10-30% during peak times daily. Unacceptable Performance: 1 Server per 250+ Developers. The network is unstable and crashes. You can try disabling connectors, disabling license checking, disabling vulnerability scanning -- but those are really important features, so your best bet will be to plan for a load-balanced scenario. See How to Prevent Server Overload in ProGet to learn more.

Hello Thank you for the tips Cdt

Hello; this is the first such request for GCP. These are extensible components, and it's possible we can support it very easily -- but we like to partner with customers, since we have very little knowledge about GCP and like to make sure it works in the field before making it public. The best way to get this rolling would be to submit a feature request, and ideally bring it up with your technical account manager to see if it can get escalated.

@apxltd Thanks for the info ! I missed this one in the documentation :/ I've disabled the caching and it works fine now

Actually, I'm not wrong; ProGet is simply not designed for your use case. It is infinitely more stable in the use cases it was designed for. ProGet also can't bake you muffins; an "oven" is much more suited for this purpose. There are lots of tools that solve different problems, and ProGet is not designed as a desktop-based, single-user "server" for personal use. We have no intention of building such a tool; our tools are designed for teams to work together, not power tools for single users. Anyways, it looks like found the tool that you're looking for. Best of luck.

Hi As I was building a test case, I found an error in my code After correction, It is working as expected. Sorry !

Yes; you would use a Docker feed and a Connector for this. ProGet will cache the container images and metadata, so it should give you better reliability when Azure container services has an outage or they introduce a new "feature" that breaks things ;)

Get in touch direct,happy to work toether on POC/implementation

We haven't heard any other complaints, so it leads me to think it's either your end (proxy?) or npm's end (blocking). We have no idea what their blocking mechanism could look like. For all we know, they could be doing agent-string filtering, and blocking requests from ProGet software, but not your web browser or npm client. Best bet is to run ProGet through a proxy (like fiddler or wireshark), by going to Admin > Proxy. Then you can see exact traffic.

Of course, plan versioning is introduced in a later version, and Rafts (which allow for Git-based storage) is coming in 6.2. I definitely understand the hesitance to upgrade, but worth noting ---- for once 6.2 comes around we'll offer some great migration tactics to let you pull applications from really old versions of BuildMaster. We'll also better support multi-instances of BuildMaster, so each group can upgrade as they'd like. That said, the Plans database table will contain your OtterScript plans. Not sure if that's a good solution, but pulling from that table will give you latest versions.

I think by default all you need is to set the host to "localhost" and the port to "8888". If that doesn't work, check the Tools > Options > Connections tab within Fiddler for the port number.