Awesome ! It works like a charm ! Thanks !

Looks like a bug caused by accessing certain pages from clients that don't support gzip compression. We'll have this fixed in 4.0.15, which should be released today. Thanks for the detailed report!

This is by design. The "Packages" listing page (/packages) lists the packages (and all the versions) stored on the local server, across all feeds. The "Feed" page (/feeds/FeedName) will show the aggregated view of packages on the local and remote servers, collapsing all the various versions into a single version.

I understand... you want the ProGet web server to host/serve the icon files themselves... It's very unlikely we will implement an image/file hosting feature. There are plenty of image/file hosting servers out there, or you could just use a basic IIS site to serve files from disk. Note that, on the NuGet roadmap, there is a feature to store icons in the package, like ProGet's universal packages does, using package://myicon.png; this would simplify things quite a bit.

I think I know why, The query shows either targetFramework='unsupported' (for update2 xproj) or targetFramework='DNX451' (for update1 xproj) I think it should use targetFramework='net451'

This has been logged in our issue tracker - it will be fixed in the next release, which will be v4.0.11. We should have that available early next week. It looks like this was just an oversight on our part.

Thanks, this works :)

I'm afraid we don't have any tutorials for this ourselves, but there a lot of third-party tutorails out there for using mvn. Here's one that might be helpful, directly from maven project:https://maven.apache.org/guides/mini/guide-3rd-party-jars-remote.html

This is by design; symbols work quite weirdly for native packages, and don't follow consistent conventions like .NET packages. So, we can't arbitrarily strip all .pdb files (we only remove them from the /lib path). In this case, we suggest to make a separate symbols feed.

Yep, you are awesome. I know this is an old post, but it was my issue as well. Using a nginx proxy for the server. Thank you.

With any versions of ProGet – from free to Enterprise – you’ll be able to access the repositories but scaling down from Enterprise to basic, or basic to free , you'll lose access to license filtering, feed-level user privileges, and other benefits that many users have come to enjoy, depend on, and take advantage of throughout their use of enterprise or basic ProGet. Very rare are there cases folks want to lose those features but if it's necessary, your team will still be able to access the repositories. Take a look at the full break-down of features and benefits per version here: http://inedo.com/proget/pricing/features-by-edition

Alright, well I did manage to make it work using IIS so at least there is a workaround, however since that was the only thing on that server that needed IIS it's too bad that I had to install and configure it only for that purpose. Thanks.

We have been running the update since it has been out and it does look like it has fixed our issues with random failing npm restores. Running my LinqPad test script now (which makes 32 concurrent requests for the same resource), still makes it "fail", but now with a 404 as you described, instead of returning an empty package. (Which is still quite weird behavior IMO...) Thanks for the quick response and help on solving this!

As far as I'm aware, the original issue in this thread has been resolved long ago. If there is a new issue with pulling connector packages, please post a new question.

Yes, but it's not "officially" scheduled as BuildMaster v5 is the top priority at the moment. Here is the roadmap for reference: http://inedo.com/proget/roadmap

We will explore this further; NuGet 3.4 added new abbrebrivations that we will be supporting in the next maintenance release.

Understood! Thanks for the quick response. Btw, it would also be nice to have a "Clear All" button in the recent errors section, because when we start having a ton of the same error, it fills it up and we can't clear them easily. Thanks again!

You might be getting that message if you have Windows Integrated AUthentication enabled; this is unfortunately not supported in the npm client. Otherwise if you follow the steps in the npm tutorial it should work just fine.

This seems to be unrelated; the problem before was that ProGet was not providing a 404 when a package was not found, but instead an empty result. Also, we cannot reproduce this error at all, so it's isolated to yours. As such, please Ask a New Question as not fill this one; and also make sure to provide a stack trace of the 500 error message; this can be found in Admin > Error Logs.

This would require creating an after-push adapter using the sdk. Several folks have done this in their own instances, but we currently don't hav ea tutorial for how exactly to write one;, but the classes should be fairly self-explanatory to assist with this.