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.

Sounds good, by early next week we'll have some very specific documents that include exact deployment plans showing how we personally handle some cases with dependencies (specifically, how the BuildMaster installer deployment is automated, even though it depends on 4 separately-built BuildMaster extensions and BuildMaster itself). In the meantime, the feature as we've categorized it is Dependency Management: http://inedo.com/buildmaster/features/dependency-management

We've seen this happening with some connected feeds, and unfortunabely there is no workaround (aside from not using the connected feeds). This has to do with the translation of UTC dates between External Feeds (NuGet.org) and ProGet. We will have a new version (2.0.1) out today to resolve this.

Ah, thanks; it would appear I wasn't on the latest version of NuGet... where this seems to be an issue. This is related to the aforementioned issue and should get resolved by PG 2.0.

This is a known issue (PG-61) that seems to have started with NuGet 2.2 (maybe 2.1?); our notes read as "if a package has a pre-release version and a stable version, only the pre-release version is shown." It's scheduled to be fixed in the next maintenance release.