The fake step is the way to go here since you can't force past the "deployables with dependencies" warning anyway. The only reason it's there is because it is almost certainly an error to build against a specific dependency (such as an SDK) and then release the dependent software using the SDK, but then do another build of the same release of said SDK which could break compatibility.

For the time being, you've done it correctly! We may modify the build importer to support importing multiple at some point though since this is a fairly typical use case.

Never mind, I discovered that I just need to append '&variable=value' to url

Yes. We can switch to IIS. Login time out is not a problem. The problem is that our CI builds were taking much longer depending on ProGet needing to spin up. I'll let you know how it goes.

That value is in seconds. For the performance aspect, it should be relatively fast with your number of packages. Do you by chance have a wildcard connector filter configured for the feed? That is what typically adds the most time to package requests, as the requests to the connected NuGet feed end up using the OData "startswith()" function which is not the most efficient. Otherwise, if you don't have a connector filter and are experiencing slow downloads, once the new indexing method is implemented (scheduled for v3.3), the delays should go away completely and you shouldn't have to restart the service. As implemented now, there is a FileSystemWatcher that monitors the entire package directory, which can do strange things with lots of files, especially when the packages are stored on network shares. In the new version, it will monitor only an empty drop folder, and once packages are put in it, move them into a subdirectory format like "/package/{version}/{.nupkg-file}". We are beginning development on this feature starting today now that our v4.5 of BuildMaster has been released, so keep an eye out for the next minor release. Note we may actually add this feature to a maintenance release of v3.2 without formally announcing it, so check the release notes to see if it's included.

This depends on the setup, if you use Integrated Windows Authentication, you cannot have anonymous access to any feeds because the authentication will be required before the request even hits ProGet. However, there is an option on the "All Settings" page named "IntegratedAuthenticationEnabled" that when set to false will allow you to use the Forms-based approach using your Active Directory credentials. Another option with regard to the build server is to just copy the .nupkg files on disk to the feed's storage path, which will in turn be picked up by the indexer and added to the feed.

That's a good question! Currently, the web interface doesn't use any of these adapters (as you have discovered), but in an upcoming version, we are going to change the way package upload/indexing works behind the scenes and will incorporate the adapter at that time. As far as scheduling that goes, we're aiming for v3.3 to be released in the next couple of weeks.

Just add the feed as per normal and when you want to add or update packages, Visual Studio will pop up a message box that allows you to enter the credentials for the feed when you select "Manage NuGet Packages..." or "Manage NuGet Packages for Solution..."

I'm guessing that your AAA.BBB package does not have a .nuspec file in it, or it is not named AAA.BBB.nuspec. This behavior hasn't changed since 3.1.0, but it's possible that it just didn't used to get logged before. You may want to open up the .nupkg file in package explorer or a zip utility to check it out.

The built-in action only supports setting the value for a known variable, but you could either write a custom action/extension or add 3 actions that set: key=(value) => $Value (key)=value => $Key Then add a Set Variable Value action that sets $Key = $Value

Can you try updating to v3.2.1 (the newest at the time of this writing) and see if your issue is resolved? http://inedo.com/proget/download

This behavior is supported, yes; however, starting/stopping services requires Admin privileges. Does the user hosting the BuildMaster service have this?

The error is either on nuget.org's end (possible, but will go away within a few minutes) or within your network (most likely). If you have a proxy server or firewall, make sure it's configured to allow passthru SSL connections; keep in mind, default port is 443 for this... for the user that the ProGet service/web-app is running under.

The GetUpdates() method is now included in v3.2.1

This feature was actually added in v4.0, just change the workflow properties to allow deployments to any environment.

Have you seen this? http://inedo.com/support/tutorials/creating-an-auto-deploying-custom-extension-application But in short, you put {YourExtension}.dll inside {YourExtension}.bmx, where .bmx is simply a .zip file renamed to .bmx. For the ClickOnce action, take a look at: http://inedo.com/buildmaster/extensions/.NET/Inedo.BuildMasterExtensions.DotNet2.ClickOnceAction

The best solution is to assign a domain account that does have the privileges to start/stop the service. There are some other solutions detailed here: http://serverfault.com/questions/187302/how-do-i-grant-start-stop-restart-permissions-on-a-service-to-an-arbitrary-user

This question is answered here: http://stackoverflow.com/questions/26592119/buildmaster-net-framework

You can reset the Admin user account password by stopping the ProGet Windows service, then running ProGet.Service.exe and selecting the "ResetAdminPassword" option. Make sure to restart the Windows service when finished.

Your best bet would be to run a fiddler or similar trace to see what calls monodevelop is making vs visual studio. There is really no documented standard API, so it's very possible that monodevelop is using something that happens to work with nuget.org,