A 401 means not authorized; so, you will want to make sure you are using proper credentials and , if you have integrated authentication configured, then it's working for the account using the NuGet push.

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.

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.

Thanks for the report. We'll have this fixed in v4.5.4, which will likely be available today.

It would be nice if you could avoid this error? It's filling up the error log, making it hard to find the actual errors.

The Release & Deployment API was added in BuildMaster v5.5 so you'd have to upgrade to use it. As for the /api/json page, it shouldn't require a key to view the methods so there's a bug there and I've added that to our internal issue tracker.

Found the problem: It was an incorrect credentials at the connector.

What version of Otter are you using? This was fixed in a newer release, but it's possible it's a different case...

BuildMaster runs the PowerShell scripts in-process, so it's not possible. The method you've identified (running a separat eprocess) is the best way to accomplish it I think.

To downlad a package, you'd need to use the feed-specific API (NuGet, npm, etc). The SDK is really only designed for building extensions.

I ran into the same issue when trying to run image on docker on windows (in linux container of course). First thing that I tried was to turn off proxy server. After that, instead of seeing an "Activation completed" message, activation request never finished. In the end I restored original proxy settings (same as system), restarted docker image and activation went without any issue automatically after restart.

If you are getting a browser pop-up authentication (as opposed to a ProGet login screen), then it means Windows Integrated Authentication is not working. This is due to configuration of your server or domain. Unfortunately, this is performed by IIS/Windows (not ProGet), which means the request is never reaching our software; this means we can't provide any information about why it's not working. But this also means there are a lot of resources/articles you can find to give debugging on how to get it to work. I would suggest searches like, "Windows Integrated Authentication always authenticates" etc. Please post what you find!

Currently the license filtering is only supported for NuGet-feed types, but we are planning on a license management module coming soon that will handle this much etter for npm and other feeds.

SOLVED See the following Stack Overflow question fro the solution. http://stackoverflow.com/questions/3853767/maximum-request-length-exceeded In summary: in the web.config <configuration> <system.web> <httpRuntime maxRequestLength="2147484" /> </system.web> </configuration> and <system.webServer> <security> <requestFiltering> <requestLimits maxAllowedContentLength="2147483648" /> </requestFiltering> </security> </system.webServer> Note: maxAllowedContentLength is measured in bytes while maxRequestLength is measured in kilobytes, which is why the values differ in this config example. (Both are equivalent to 2 GB.)

This is an internal GIt error, and can usually be resolved by just deleting the local repository (under the TMP\SrcRepos folder).

It's likely that the user installing does not have the ability to access the database defined in the configuraiton files on disk. So, make sure to run as a user that has DBO on those databases.

This regression was fixed in ProGet v4.5.0. I'd recommend upgrading to the latest version.

Yes. We do this ourselves when we release BuildMaster as the installer relies on the BuildMaster software itself, a few independent embedded extensions with differing release numbers, and also handles releasing a source code package to inedo.com so Enterprise users can download it. The way to do this is to create a meta-application of sorts, and then create deployment plans in that application that create packages or deploy packages for specific releases in other applications. Here are some of the operations that would be useful: http://inedo.com/support/documentation/buildmaster/reference/operations#BuildMaster

Is this for a legacy plan action or a OtterScript operation? If it's for a Legacy Plan, you can edit the Configuration Profile for the NuGet extension and specify a path to your custom NuGet.exe in there, and actions will use that instead of the default one the extension ships with -- this way you don't need to overwrite anything. If it's for an OtterScript plan, you can override the default location by creating a $NuGetExePath variable at global or server level with the value being the path to your version of nuget.exe on the server. This is the new style of configuration that replaces legacy Configuration Profiles.