There's nothing special that ProGet is doing, it's effectively just inserting a SRCSRV stream into the pdb, exactly as pdbstr would. I'd also check out #3061, and specifically http://techblog.dorogin.com/2012/09/troubleshooting-debug-symbols-indexing.html

Note this response will be handled via an email chain and will require either a new SVN extension or require a change to BuildMaster to resolve. Also see the following thread on GitHub: https://github.com/Inedo/bmx-subversion/issues/9

This is no longer a supported feature. Very few customers used it, and it caused a lot of headaches when it was used. We may consider adding it back; in the meantime, you can write a script to retrieve packages from a connector, and copy them to the drop folder.

The "load from" options were removed in v4.5, I'll add a note to remove that from the tutorial. Updating the screenshots is already on the list to update as well.

Currently, we only support the synchronization / replication of specific feeds using the MyGet sync feature. We may offer a ProGet <-> ProGet feed sync feature in the future, but there's not a lot of demand for it.

ProGet on IIS is only supported as a root level web site of IIS - it cannot be a virtual directory of another application. If this is not an option, you'll have to go with the built-in web server option.

Ah, I see. We have been able to reproduce this - it looks like a regression in handling the feed-specific npm adduser URL. We've also always handled the /siteroot/-/... one as well because npm used to always use that regardless of the repository URL. I think that changed some time around npm 2.7 when we added the second handler. Regardless, we've already fixed this internally (again), and will be releasing the fix as part of ProGet 3.8.1 likely some time tomorrow. Thanks for the help!

For all lookers, answer chain above resolves the question Awesome, thanks for the great support. I'll look forward to the Extension, in the meantime I think I have enough going now to generalize for the rest of our environment. Thanks for the assistance, and as I mentioned -- the product so far is excellent and we will definitely be purchasing the Enterprise as soon as I get quotes back! ;-) Cheers!

Thanks for the bug report! We've reproduced this and have fixed the bug in one of our pgSQL functions that was causing this. We'll have the fix included in the next beta (4.0.2) which will likely be released some time today. FYI- it's the same bug preventing changing the password on that page and adding a new user; we have verified that both are now working.

The upgrade is a coincidence, and the problem could have been triggered by something as simple as restarting the application pool; this is handled entirely by IIS (more specifically, Microsoft Negotiate). Negotiate authentication uses Kerberos (see Kerberos Explained), and this is difficult to debug. You can search for things like “windows negotiate authentication fails” to find all sorts of tips, but this article has been a good resource. In my experience, the most common reasons this doesn’t work: accessing by a different url (buildmastersv vs buildmastersv.mydomain.local) having a time difference between server and domain controller not having certain patches/windows updates NTLM is a different type of authentication, which may not be desirable.

Yes, run the Admin Tool from the start menu.

As long as your support renewal is current and either you are upgrading the instance directly, or you have purchased enough server licenses to cover all running instances; it will just work. If you attempt to activate a key on a new machine that would cause the number of running and activated servers to be greater than the number of purchased licenses, there may be an issue with the activation and you wouldn't be able to use the software. For more advanced or specific scenarios, you might be better off contacting us directly.

This answer doesn't answer the question. Is there anything else to check or try?

The SRCSRV stream for downloaded PDBs was always empty. Once I added that stream ProGet correctly updated it to point at itself. I never saw errors on the /administration page of ProGet. Is there somewhere else to look? I'd like to be able to skip the local indexing step if possible.

You can move BuildMaster from one server to another using the backup and restore instructions. However, I would suggest using the built-in retention policies to purge old items instead of that script.

Yes. Currently different versions of our websites get deployed to the server to a directory based on the version number. Was interested in just changing the directory the website was pointing at after the artifact was deployed. We currently do have a builds/deployments using a bunch of PowerShell scripting but it is getting challenging to maintain. Thanks for pointing out the Windows Extension.

Ah I missed the snapshot creation option, because I only tested an existing ProGet 3.7.x maven feed I had. The checkbox is handy when creating new feeds since it'll save the step of whipping up another feed. Since nothing appears to prevent you from creating your own snapshot repository without the checkbox, and the snapshot feed appears to be fully configurable and separate from the other repository (which one would generally setup as a RELEASE repository) so - yeah - that feature seems good to me. Thanks a ton for adding the storage location override to the next release - that's really going to be useful. Of course, now I'm getting excited... so I have to beg for feed retention rules being made available for snapshot repositories as a free version feature -- like Nexus, Archiva, etc. If that happens, my journey to the dark side will be complete. :-) I can understand the wisdom in making that a pay-for feature for most all other repository types, but at least for maven snapshots, the general industry standard is to provide some mechanism to auto-purge snapshots (keeping only the last 3 - or whatever the user specifies, etc.). I can also say that these specific improvements being made will help making a stronger case to switch binary repo managers, as well as going pro to pick up the other enterprise features. So thank you for the help and new features!

We're currently running BuildMaster and their agents under the same account. If we can turn off the "agent" role within the Server, it would help us achieve a clear segregation of concerns. We can then narrow the security the server's account runs under and since it won't be doing anything other than coordinating with agents, we can lock down the ports, etc. Ideailly, we would like to achieve the following: BuildMaster server (lightweight, has no source control providers, no dependencies installed, does NOT build anything) BuildMaster build agents (has source control providers, SDK's, etc.) BuildMaster deploy agents (on the actual target servers the apps should be executing on )

Thanks for the clarification. But then you should disable the ability to add anonymous as a group member and show a corresponding warning. With kind regards Boris Bopp

Your best bet will be using either a Delete files action, or simply just the Transfer/Synchronize files action, along with some negative/exclusionary masks. For example... * !images !cache !web.config