Glad to hear it! Thanks for letting us know.

Just an oversight. It's pretty trivial to change so we can get it in 4.5.3 today.

Have you looked at ProGet's deploy features? We switched to using those from Octopus, sooo much simpler for our configuration (no agents... plus we could just do a choco install if we needed to), and you could add w/e pshell scripts you wanted.

Panic over, ntlm authentication rather than basic authentication required.

Within a few days or so we are planning to release a new version of ProGet that has a new indexing system, which should no longer lock files like this. It will require a new feed type, but it should resolve these issues, and be much more performant than the current implementation.

I figured it out. Forgot to add ASP.NET 3.5 as a feature. DOH!

This error is coming from nuget.exe; depending on the version of nuget.exe you're using, AD / integrated authentication simply will not work. It's supposedly fixed in 2.8.2, but some users say it doesn't work in 2.8.3. It's pretty broken in 2.8.1 and 2.8.0. Although it sometimes works in 2.7. The 2.6's seem to be fine, for the most part. ProGet.exe, from the now-defunct client tools, of course will work fine, or a simple HTTP PUT operation.

Using a \ character is correct for escaping in JSON; that should work. We will try to reproduce this, but in the meantime are you able to use single quotes instead in the XML? Assembly='BuildMasterExtensions' should also parse as valid XML if I'm not mistaken.

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?