There is no special path; a cached packages is stored under the feed's package store, alongside regular packages.

A "legacy" NuGet feed is a single folder; it's possible it's a different location than \Packages\Default if you configured it later.

When the new SQL Server is installed, simply backup and restore the existing ProGet database to the new server, then update the connection strings in the .config files located in the Service and WebApp install directories so that they point to the new server.

UPDATE: This is a breaking behavior change planned for NuGet 3.4. https://github.com/NuGet/Home/issues/2298 This may not have a large/widespread impact, and it might be difficult for us to fix server side without breaking everything other than NuGet 3.4... so for now our advice is "don't upgrade to 3.4 or don't rely on that behavior". Please update/share if this issue impacts you.

Nevermind. It was due to my local cache in ~\AppData\Roaming\npm-cache so npm never tried to fetch them from the server. I cleaned it out and ran npm install and now everything works! Sorry for the noise.

I am getting this same issue, i guess the best thing to do is to use a third party app like Long Path Tool. Just download it and use it to solve this issue. I hope this would help.

Thanks. That would be great to, app to app, I am referring to within an app itself. But it sounds like both would be the same so that would be perfect. Looking forward to 5.

That's unfortunate, but understood. Thank you for your timely response. However, I certainly wouldn't classify the workaround as easy with an actively released package such as EasyNetQ. Am I right in assuming the workaround would require manually monitoring for new versions on NuGet and pulling the new packages to ProGet whenever a new version is released? If so, that is quite an administrative overhead. I'm sure there are other packages on NuGet which have crossed the 100 releases boundary (or are nearing it), so this is probably not an isolated case.

In this case, you will need to diagnose why your computer (client) is unable to connect to the server (ProGet). It could be so many things.... bad wireless reception, the server is turned off, or anything in between. Suggest to use Wireshark to see where packets/information is being lost, or work with your network engineers to see why this is happening.

Unfortunately there's not enough information provided for us to provide any assistance. I'm not sure what feed/package type this is (NuGet, npm, etc), what version you upgraded from, how you're trying to use ProGet, what specific errors you're receiving, etc.

Please note, the 4.0 upgrade notes discussed the changes to permissions. So in v4, you will just need to edit the "task" that you want to give privileges to.

You can use the "Anonymous" pseudo-user, but note that "Windows Integrated Authentication" is a protocol (not unlike HTTPS) that requires negotiation by the client/server before getting to the application layer... and unfortunately it's not possible to have WIA enabled on some urls/feeds and not others.

It's hard to say... 3.6 was almost a year ago, and I know the npm api/format specification has likely changed since then. So, it could be a related to that...

If the JIRA release operation should happen anywhere other than when the release is deployed in BuildMaster (i.e. using the event listener), you'll have to add a custom action or use PowerShell, etc. Alternatively you could fork https://github.com/Inedo/bmx-jira and add it that way, here is the tutorial for that: http://inedo.com/support/tutorials/cloning-and-patching-an-inedo-extension

There weren't any major, systematic changes that would have caused this to occur. Most likely ,the service isn't running, etc... I would roll back to the old version, then try to do the upgrade again.

Hi Owen, you can just run the ProGet.Service.exe, and there will be an option to reset the Admin info and directory provider.

FYI - that's the "Operation" for our Otter product, but the BuildMaster Action works about the same... But in either case you will need to have an agent installed in order to stop the app pool on that server. Alternatively, you could use powershell script to do it, but that would require additional ports and the like be open on the remote server (RPC, maybe?)

Unfortunately the behavior of Visual Studio's Debugging/Symbol Serving can be a bit strange; there's not much we can do to control that... however if you carefully follow the tutorial, it should help you get set up!