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

what if we try it on a sub website i mean a subdomain? it will work or not?

Hello, Would it be possible to ask a follow up question to this... Are you using Visual Studio 2010? I tried to find the setting that you mentioned here, but I can't find it in my Visual Studio 2010 setup, and I am wondering if this is only possible in Visual Studio 2012. Thanks Gary

You're right, at the moment the LDAP provider uses whatever domain it happens to be a part of. We'll put it in the roadmap, but we also offer the ability to "speed up the process" so-to-speak for our enterprise customers via our professional services. If you would be interested in this option for your organization, just send us a message using the contact form (http://inedo.com/contact).

Good idea. We should be able to add this feature in ProGet's next release.