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.

Feel free to contact us at support AT inedo DOT com as well... sometimes easier to have back-and-forth discussions for feature ideas :-) Interesting idea; we haven't had this requested before. We'll be introducing an SDK in ProGet 2.0, so that could make things like this easier to do as well. We'd be curious to see some specifics, or some packages you know that have complex enough dependencies that a graphic would help.

We wanted to include versions in our Connector Filters, but it wasn't really practical. If memory serves correctly, NuGet's ODATA implementation sees version numbers as strings, thus you couldn't do version ranges or anything like that. I think someone on our team submitted an issue to NuGet about this, but as far as I know it's still treated as strings. So, until then, your best bet is to manually craft your feed. One trick someone suggested was to create a feed with a connector to nuget.org and then download packages to a "Allowed NuGet PAckages" feed (no connectors) --- both of which share the same local directory.

In ProGet 1.x releases (current), package metadata is not stored in the database -- it's just in-memory, and is recreated when the server restarts. In ProGet 2.x (coming soon), we will be storing package metadata in the database and will thus have an ability to retain this information. We'll also be integrating some more in-depth package usage analytics using some bits from Gibraltar Loupe ( http://www.gibraltarsoftware.com/loupe/Default.aspx ) -- though that likely won't make the 2.0 cut.

Hi Steve, Thanks for the reply, I think this is best illustrated with a screenshot or two, which I shall send to your email address as mentioned in the other answer. Thanks, Adam.

Hi, Thanks for the prompt reply. We're in the process of getting this running to hopefully become one of your enterprise customers, and it definitely was a problem for us unfortunately. Obviously I do appreciate this isn't actually your fault...!! Rather your workaround for someone else's issue. We would definitely be interested in pre-release versions, as we are still in the testing/implementation phase, it will be simple for us to move up and test. Thanks again! Adam.

I talked with our IT HUG and he changes the MAC address setting from dynamic to static. I hope this will solve the problem. Thank you.

Ah, definitely a bug -- will be fixed in next release, (1.1.4 or later)

It is possible (and fairly easy), but we do not have instuctions just yet. Hopefully this response will be enough. It basically follows the same steps as the Manual BuildMaster Installation ( http://inedo.com/support/documentation/buildmaster/installation/manual ), just without the Extensions or Agents. The hardest part will be getting the artifacts, as we don't have those available for download yet. But it's not so bad. For the files (WebApp and Service), you can just directly copy out of an existing installation. Just make sure to edit the appropriate appsetting config files when moving to the new server. For the Database, you can restore a back-up of the existing installation. To upgrade, you can use 7-zip to open the installer, and then copy out bmdbupdate.exe and $_OUTDIR\OBJECTS\SqlScripts.sql. First run bmdbupdate.exe then the .sql scripts. We will definitely make manual install artifacts avaiable in the future (along with instructions), and we do support this scenario for Enterprise Customers. We'll even help with install through our Professional Services ( http://inedo.com/company/professional-services ). Hope this helps...

The only way to disable the API key is to enable LDAP authentication, which requires the Enterprise edition of ProGet. However, as an FYI, if you do not specify an API key for the feed but are using built-in authentication, the API key follows the pattern "username:password".

I think so, Gary. Thanks again for the pointers. I'll be sure to ask if I have any more questions. Have a great day! Matthew