I have experienced what I suspect is the same problem. The package file works if downloaded manually via the website or if downloaded WITHOUT contentonly. If downloaded with contentonly=zip the package is empty. Installing the package via UPack results in an empty package as well. For me, this problem occurs when creating the Universal Package zip file using PowerShell's Create-Archive command. If I use 7-zip or UPack the problem does not occur. This is a bizarre problem and should be addressed as many sysadmins probably reach for PowerShell first. This kind of problem is near rage inducing :)

Yes, that's precisely what it would be; an ATOM feed for private galleries that you can push extensions to. I think only MyGet supports it now, so we will look to them for how they handle pushing, so it can be consistent. Most of our enterprise customers wanted to create a workflow like they do with NuGet.org, with only certan public packages in the feed, etc. THat is, they didn't have custom extensions, they only wanted to restrict or cache public extensions for their developers.

Just to clarify... the "NuGet v3 API" is intended for internal-use (i.e. only nuget.exe and NuGet VS extension). Microsoft's new position is that they do not intend on making this API public or stable in the foreseeable future, and that they will continue to support the "NuGet v2 API" (which is documented and public) indefinitely. They actually use ProGet to test changes to v2 API. That said, until this position changes, we will not reverse-engineer the v3 protocol. So this means you will need to use nuget.org/api/v2 in your connector, not the v3 url. Both v2 and v3 API work with client tools, both support DotNetCore, etc. If you're finding a issues with DNC projects, then it's likely related to framework monikers or something like that. Please submit a ticket for this with specifics, so we can investigate and patch.

Spectacular - that was exactly what I was hoping. Thank you for taking the time to answer!

It's hard to say, so we'll need to diagnose a bit further. Could you submit a ticket for this, with the following: which packages work? something from a package that doesn't work... package type (NuGet, npm, etc) metadata file (like nuspec, package.json, or entire package is fine) screenshot exhibiting this behavior With this, we can go back-and-forth over email a bit easier.

Auth tokens are now supported for npm feeds; you'll need to create the token as a ProGet API Key. Please see the API & Access Key documentation to learn more. This is an updated answer; earlier the answer mentioned the feature was not supported.

There is a "multi-domain / forest" AD provider. As long as the domains have a trust to eachother, then the users from the other domain will be enumerated and it should "just work". We are considering building a new active directory provider that allows you to explicitly list the domains to query (instead of doing a trust search), but that ended up getting really complex fast, so it's on hold just for a bit...

Thank you so much. This is exactly what i'm looking for.

ProGet does not support this for a variety of reasons, primarily security and support. Some users set-up a reverse proxy and rewrite urls, but we don't recommend it. Instead, please just use a different host name (Proget.mycompany.com) or port (mycompany.com:1000).

This is what Retention Policies are designed for, you can configure them to do this.

Hi Team, Thanks for all your support. I was clearing the temp cache for symbol server. Cleaning up a nuget cache fixes the problem for me. Thanks.

Oh god, worked ! Thanks a lot ! Would be super great if there could be a message or a log that says why the operation ended in a brutal closure of the program ;) Just a last remark: I may be wrong but it looks like you did not generate the "Full installer build" since a long time ago. If you look at the download page (http://inedo.com/proget/versions), event if full and small installer links do not lead to the same endpoint, the download size is the same wherever you click. It looks like the small version is deployed on all the endpoints. Thanks again for your help ;)

The Feed Clean-up task, which is run from the service on a schedule you define in Admin > Tasks, will clean up these. if it's not happening according to that schedule, please ensure the service is running. You may want to restart the service. You can also manulaly trigger it too; if you do that, then it will clean up the missing packages right away.

In this case, you are pointing PRoGet to a SQL Server on a different machine. You will need to either use a different connection string (name/[assword), run proget service/web under a domain account and continue to use integrated auth, or allow connections from that machine in SQL Server (not recommended).

Solution found, wrong app pool user. thks all

Alana- looks like this one is actually on me, the reverse proxy was stopping the single quotes. But, the extra trailing slash is what causes the issue with Packages(), same as it does with the earlier problem. I have it sorted out now.

That's what the nuget.exe client does, a Delete method. Yes. That will also remove package from disk and metadata.

The resources are embedded in the ProGet assemblies (in this case, InedoLib.dll), so if you can hit the site, then it means some IIS setting is preventing those from being served. It's hard to guess which one... perhaps URL filtering?