Hello Please ignore my question. The downloaded nupkg file was faulted. Thanks

Thanks for the update; we do have a work item (PG-130) for improving indexing of .pdb/source on large packages. This will come in a future version, hopefully soon.

We actually have two use cases for delete: maintenance scripts (we have beta packages published for each commit so we need to perform periodically cleanup) automatic validation of new ProGet releases (so we can quickly "validate" a new release before move it into production) I know they aren't common use cases but it will be useful.

Does this happen with all packages, or just one package? Can you try pulling a package to the feed (like JQuery), and then deleting it? Can you disable friendly error messages (webCustomErrors=off in advanced config), and post stack trace?

I am sorry. The package that still caused problems had a version number like 3.40.0000.0. This seems to bother a nuget 2.7 client, but not a nuget 2.6 client. The problem disappeared when rebuilding the package using the 3.40.0.0 version number.

Hi John, I just tested the fix, and it indeed solves the problem. I am impressed how quickly this was handled! Thanks a lot!

Hello, We've identified a bug that's causing this.... it will be fixed in ProGet 2.1.3. In the meantime, if you email support at inedo.com, we will send a patch to resolve this. Thanks, Steve

Unfortunately that issue PG-119 was moved to a future a release because of the priority of the other issues listed in the release notes: http://inedo.com/proget/release-notes#2.1.3 We will try to get this in 2.1.4.

Ah, yes, that is indeed a bug. The home page "Browse" should link to the first available feed. I've logged this as PG-121 and we will fix in a future version of ProGet. The "Feeds" navigation link, however, will show the available packages.

Hey, This is great news! Thanks for getting this sorted out so quickly! Gary

Hello, Thanks for the reply. I have started pushing just the Symbols package, and this seems to be working really well. Thanks Gary

We uncovered the cases in which it might lock... this should be addressed in ProGet 2.1.2 (released today).

Great, many thanks for your support!

There's no specific error message, aside from the SQL error that's being thrown. Since you have both on the same server, perhaps it'd be best to have a single SQL Server instance (SQL Express), and have the BuildMaster and ProGet databases hosted in that server.

Thank you Alex, as you suggested, the issue has been solved increasing the maximum allowed content length in IIS.

Thanks for this! We also use ProGet for internal assemblies and having symbols readily available through the NuGet package saved me from having to hack something together so we could have easy access to the PDBs.

Thank you, it did solve the problem.

I ended up just installing for SQL express, then taking a backup the database it created and restoring that on our sql server, and pointing the service and web app to that. Then I changed the service to log in as the domain login that has rights on the database. It would be nice it we could specify a database name when installing, and use an existing empty database. Also it would be nice to be able to specify the windows user accessing SQL when installing. Right now when installing the database creation script runs as the user running the installer, and the service itself runs as Network Service.

Thanks guys! The 2.0.5 release appears to have solved the connector problem.

The "IsAbsoluteLatestVersion" is an undocumented NuGet attribute (well... it's in the source code), and has a confusing relationship to the quasi-documented IsLatestVersion attribute. Long story short, these these attributes tend to behave differently in different versions of NuGet clients, and our changes to remain compatible with the upcoming NuGet 2.5 caused a regression. You shouldn't have to change anything in your packages -- just post here if you find issues and we'll figure it out.