Correct; that, and the API key, are what get sent over.

I trying http://myExample.com/nuget/Default to http://myExample.com/myframework/packages . But i changed baseUrl = http://myExample.com/myframework/packages/nuget/Default

My best guess is that it's related to permissions- most likely the user account which is running the service cannot talk to the SQL database. There should be an error/exception in the Windows event log if this is the case.

We actually haven't tried using SBT just yet (in fact, I just learned about it from your post). But generally speaking, one of challenges with Maven is that it's convention-based, and doesn't have any documentation on the convention. So it's possible that SBT is using a slightly different convention than Maven or Ivy clients are. Moreover, different "packages" have a convention to behave differently... Would you able to attach Fiddler and see where some of the discrepancies in the request/responses might be? Sometimes it's incredibly obvious, and that might allow us to implement yet another undocumented convention. It may be easier to communicate over email, so perhaps fill out a ticket or just email us at support-at-Inedo-com once you have some details?

You can just use the license key on the new server.

For completeness: An alternate approach is to create a private source server and update to both the source server and to the Universal Feed from out in-house deployment tool. But we were hope that we could have pig-backed on what you already had. Oh well. Thanks.

It looks like there was a regression in 4.6.0 that is causing this change in behavior. We'll have it fixed in ProGet 4.6.3, which will should be released by tomorrow at the latest.

Verified - the problem is resolved after upgrade to 4.6.1. Thanks!

https://github.com/PowerShell/PowerShellGet/issues/76

An "Access to the path is denied" message is coming from Windows. Permissions aside, a likely culprit is anotherr process (anti virus, backup, etc) is locking the file and preventing access. Sometimes you'll need to use ProcMon to identify what this is. ProGet does not requests locks when reading files.

I see; have you've tried putting in your npmjs username and password in the connector? If that doesn't work, then it's not a supported scenario.

We'll add that as a proposed feature. I think the only issue aside from a small query/performance issue in implementation is that dependencies can change for different versions, so we'd really just be showing the latest version's dependencies there. Still, we are already doing that with certain fields like description, so that's not too bad...

The admin tool does not currently add the user back; but you can do so directly in the database; the tables are fairly straightforward. To reinstall, make sure to drop the database after install well. It does not get removed by default.

The only thing that will yield this message -- The process cannot access the file '...' because it is being used by another process. -- is another process having a lock on that file. Windows does not provide information about which process that is. So, you'll need to use a tool like procmon to see file handles, and identify the culprit.

I had to change 2 things when I had this problem on my windows computers. 1: I could not use the ip-address because of SSL errors - I had to use the host name. 2: I had to make sure that I logged on to the correct port. Your example was 88 in both login and push, but I forgot to use the port in the login command (I was using port 443). Perhaps this will help someone having the same issue.

This is a "false positive". See KB#1113: Anti-malware False Positives, Code Signing, and Safety of Inedo Products for more information. Please Report the False Positive! Please let your malware protection provider know about the false positive; the more people who do, the greater the chance they won't flag these in the future

There is no upper limit. NuGet packages shouldn't be more than a couple megabytes; and the more zeros you add, the more you are using the wrong tool for the job, and will have problems with how the client handles local machine caching, etc. A ProGet Universal Package is designed for gigabytes, on the other hand.

Aside from following the general back-up/restore instructions (database / package store / config files), there's nothing else to configure on ProGet. If you're getting errors, then something wasn't migrated properly. If a different file path is reported in an error, then a different file path is configured in the new instance; check out the error message under ADmin > Errors to see what the 500 was getting.