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.

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, 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.

Yes, just edit the value of the Core.BaseWorkingDirectory key in App_appSettings.config file in the service installation directory. I believe you'll have to restart the service in order for it to use this value as well.

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...

Code sent! hope this helps. A general rule of thumb... An action that inherits from ProviderBasedAction<T> is designed to run an operation on a single provider (Issue, Source Control, Database, etc). The provider and action plumbing take care of the agent and cross-platform things. If the provider doesn't already do what you want it to, then it's almost always easier to just run a command-line action (CommandLineActionBase), as that takes care of all the process logging and other things.

Well, I guess it wasn't meant to be. I just ran a build and that error came back. I set that flag back to false, ran another build and the error went away.

Are you using IIS or the integrated web server? You may want to try the integrated web server. It's possible an IIS/system-wide setting is overriding some of the configration.

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

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".

This appears to be a problem with the tests themselves. I would take a look at the Cleanup method and see what objects could possibly be null. This post (http://stackoverflow.com/a/10751484/44765) shows the some of the differences with running in the command line MsTest vs. Visual Studio.

Are you trying to create a new instance ("tab") on the config file? If so, and if you're getting that error message, then you'll need to go to "Manage Instances" and click "Show Deleted" in the top of the window. From there, you can undelete the instance.

This has been updated; Oracle Extension 3.1 now supports multiple commands per script. You can update this from within BuildMaster

Hi Joe, Sorry for the poor experience... we do strive for a easy OOB experience, but obviously have only so much control over the underlying platform (IIS). SQL Server is required, but you don't have to install SQL Express; we'll try to clarify the "use your own" option on the installation screen. SQL Express is provided for those who don't have a SQL Server instance to use. We don't have much control over the obscene amount of time it takes, but that's why Lights Out is there... The redirection is a result of some IIS configuration. It could be a LOT of different things, maybe .NET 2 isn't installed/configured/enabled, maybe a global handler is there, etc. This is why we provide the integrated web server, to get started faster. Can you provide some specifics about what IIS you're using? We might be able to provide some pointers on where to start looking...

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.

I think I just figured it out. We have some unit tests running which are creating the GUID based XML file in question. I still have to do some more investigation.