We don't have a formal EoL policy, but as long as you're current on support (which, just checked, you guys are), we'll do our best to provide support for whatever version you are on. Of course, please understand that, a lot of times, the answer may just be "upgrade to a new version", and we most likely will be unable to provide a hotfix. I suggest you upgrade to v4.6 (we can provide assistance in this as well), and then schedule a routine upgrade/maintenance window (monthly, bi-monthly, etc) so that you can try to keep current. We put a lot of effort into making sure everything is backwards-compatible, and in the event something breaks, you can rollback... or we have the capability to ship a new release within hours.

If you go to Admin->All Settings and change IntegratedAuthenticationEnabled to False and click Save, then it should use forms/basic authentication with LDAP as the user directory source. Note that if you are hosting the web site with IIS, you'll also have to enable Forms authentication and disable Windows authentication in there for the site. If you're using the integrated web server, it should just work. Once configured like this, you can supply the username and password in the url for the client. There is an example of this available if you click on the configuring Bower link visible on the page for any Bower package in ProGet. As far as I know, this is the only way to get it to work.

Under that error message, is a button [Assign Privileges]. So, if you click that button, a dialog will appear that allows you to assign which LDAP users and groups can use ProGet, once you switch to LDAP integration. So, just assign yourself as an administrator.

I believe the publish bug was fixed in the latest npm; you may want to update. Or, maybe it was broken in the latest npm (v2.5.0). In that case, you will want to downgrade. I believe we tested last against v2.2.0. I would also suggest to post this on the npm issue tracker, as will help raise the priority/importance of fixing and maintaining tests to work with repositories other than npmjs.org -

I know this is old but it's still the first thing that comes up in Google when you search for the infinite build issue in BuildMaster. The infinite builds are because applying a label is technically a check-in in DVCSs like Mercurial and Git. So when you apply the label BuildMaster sees a new check-in and starts a new build, which applies a new label, which creates a new check-in, ... I haven't found a good workaround yet.

Just want to confirm that the issue is fixed in ProGet 3.4.7. Thanks!

For me, using the feed name from the URL or getting it in a header makes no difference. So for me, that's not required. Thank you.

I just installed v 3.4.6 Build 6 and it is now working. I used SQL Express installer this time instead of connecting to a stand alone sql server. Not sure if that made any difference.

hey, i just did this on my own install by creating a new feed and adding a deny for the anonymous user for the private feed. hth, marvin

Hi, I was having same issue and finally I managed to get mine working. One thing that helps you identify the issue is this using the Module window in VS: Create a console app and install package Add a break point and Run it in VS Open Module window (Main Menu > Debug > Windows > Module) Find your module and check whether the symbols are loaded (in the status) Right-click on the module and click on Symbols Load Information... Thats the main diagnostics that got mine working, what I also had wrong most likely (not too sure about them tho). I was packing this way: Perform an MSbuild on .sln Invoke nuget pack on .csproj e.g. :> pack proj.csproj -sym Instead I'm doing this now: Make sure the bin (output folder) is cleaned. Invoke nuget pack on .csproj with build. e.g. :> pack proj.csproj -sym -build -Prop Configuration=Release Hope it helps.

In short, only push the .symbols package which contains all of the same files in the standard NuGet package, plus the symbols/source. For more info, see: http://inedo.com/support/questions/1409

Hey Alana, That option sounds fine to me. I certainly think it would cut down the time to spawn up new Applications for us.

Sorry, this question somehow got marked as resolved, but it doesn't look like you ever got a response. If you'd like, you can email us at support at inedo.com with details about what you are trying to do, and we can try to give you some more specific help/ideas.

No, but this is now something we can add to non-legacy feeds.

That would be really great, thanks.

Sure, when I experienced the problem I simplified the scenario by creating a very simple hello world package and I got the same problem. I'll send that to you.

Is this a NuGet package you can send to us for testing? If not, a Fiddler trace of Visual Studio trying to access symbols would also be helpful. You can send either to support at inedo.com and we'll try to reproduce this.

Hi again. I found that if i Grant AND Deny the Anonymous user "View Only" privilege then everything is fine.

Proget 3.4.4 Visual Studio fetches the PDB correctly to the symbols cache, but then searches for the source with a local path used on our build server. Sources are not downloaded.

If the feed is a legacy feed, then the import folder is not used; instead packages can be added directly to their storage location. Assuming it's not a legacy feed: Is there anything in the ProGet error log or package indexing error log? Both are accessible from the admin page. If there's nothing in there to indicate a problem, I would try running the ProGet service interactively to see if there's any relevant non-error logged. Just stop the service, and run: Proget.Service.exe run By default, it scans the directory every 60 seconds, so you should see some info about it running a DropPathMonitorExecuter every so often.