The npm search command has been broken in npm for some time, as it downloads the entire package index and searches it locally. Due to the size of the index on npmjs.org, this stopped working for a lot of people due to npm OutOfMemory errors and various other issues. Because of this, they deprecated this form of searching in the npm client in favor of a new search API, but it seems that only npm 4+ actually uses the new API. Indexing all of npmjs.org also caused a lot of problems for our users due to the sheer amount of data involved, so we dropped indexing of any registry that supports the search API. Local packages are still returned in the /-/all endpoint, since this doesn't require the same server overhead, which is why you are still seeing those packages. Basically, you may want to try the new npm client, or just stick to searching on the web for now.

Hello Peter, Thanks for the bug report! I was able to reproduce the problem, and it will be fixed in the next minor version of ProGet (4.7.12). PG-1029

Hello Jason, It looks like the npm registry started returning empty responses about a week ago. It looks like they're having caching problems. ProGet 4.7.8 and newer support the npm search API, so indexing isn't needed to search the npm registry, or you can wait for npm to fix the problem on their end.

UPDATE: this has been updated in PG-1632 __ Hello Jonas, Deleting images isn't in the native API because the stored procedures only delete metadata, but if your CI server has access to the database ProGet is using, you can run the stored procedure to delete the metadata for the image and ProGet will automatically delete the files whenever the FeedCleanup scheduled task next runs. Assuming your docker image is named proget:443/foo/bar/baz, the foo feed has ID 42, and the digest for the version of the image you want to delete is f52fbd32b2b3b86ff88ef6c490628285f482af15ddcb29541f94bcf526a3f6c7, this SQL statement will work: EXEC [DockerImages_DeleteImage] /* Feed_Id */ 42, /* Repository_Name*/ 'bar/baz', /* Image_Digest */ 'f52fbd32b2b3b86ff88ef6c490628285f482af15ddcb29541f94bcf526a3f6c7' GO If you don't know the digest, https://proget/api/json/DockerImages_GetImages?API_Key=[your API key from /administration/api-keys]&Feed_Id=42&Repository_Name=bar/baz returns metadata including Image_Digest and Published_Date, and https://proget/api/json/DockerImages_GetTags?API_Key=[your API key from /administration/api-keys]&Feed_Id=42&Repository_Name=bar/baz returns metadata including Image_Digest and Tag_Name.

Maven repositories are traditionally just file systems organized by convention, either local or exposed using a simple web server, so a lot of repos get this "for free" by just enabling directory listings for URLs. ProGet works a bit differently and simulates some of the traditional maven structure, so it's not necessarily trivial for us to implement this; that's not so say we can't do it, just that it wasn't deemed essential. While I don't think that this is formally part of any maven specification, a lot of other repositories do it, so it's been on our "maybe" list for some time; we just haven't had a lot of interest in it so far, so it hasn't made it onto the roadmap. We'll reevaluate what it would take to do it, and add it to the roadmap if we think it's something we can work in soon.

This has been address in v4, but asa workaround, just use the "Browser tools" to edit the text on the page, and unhide the edit buttons.

We had switched to IIS hosting of the web site, and so the solution was to first stop the web site in IIS Manager before running the installer.

Sorry for the confusion... I think those should be listed as "internal only" methods, and not on the API page. Anyway, the Native API can only be used for metadata. So you won't be able to use it in this manner.

Please make sure that the Amazon extension is downloaded. You can see which extensions are installed on the ADmin > Extensions page. When the service is loaded, the extensions are unzipped and put in the foloder you referenced.

According to the mvn deploy documentation, you'd need this in the POM file for the project: <distributionManagement> <repository> <id>myproget</id> <name>My ProGet Feed</name> <url>http://progethostname/maven2/feedname</url> </repository> </distributionManagement> If the feed requires authentication, you also need this in settings.xml (the <id> values have to match): <server> <id>myproget</id> <username>username</username> <password>password</password> </server> If you want your snapshot versions deployed to a separate feed, you can add a <snapshotRepository> to <distributionManagement> in the same format as <repository> above. After that, the command is just mvn deploy to upload the package to ProGet.

It's been quite a while since I last used Maven, but I think the POM file would look something like this: <project> ... <repositories> <repository> <id>mysite</id> <name>My Site - ProGet</name> <url>http://www.mysite.com/maven2/mf</url> </repository> </repositories> ... <dependencies> <dependency> <groupId>apackages</groupId> <artifactId>new-packages-jar</artifactId> <version>0.0.1</version> </dependency> </dependencies> ... </project>

Your template can look like this: template MakePair<$First, $Second, out @Pair> { set @Pair = @($First, $Second); } And the plan that uses the template can look like this: set @Fruits = @(); call MakePair { First: Apple, Second: Orange, Pair => @Fruits }

Glad you were able to get a little further... I've added this to the our public issue tracker as PG-1026. It's currently classified as unscheduled, but I imagine it will make it into the next release.

Regarding the database migration, we don't have an export/import function.. but you can just recreate the feed and use the bulk import path for your exisitng packages.

This is what NuGet is designed for; I recommend to check out documentation at NuGet.org on how to ge started.

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.

I'm having the same issue. When using this command "nuget.exe push -Source "http://{MyServer}/nuget/default/" -ApiKey "{USER:PASSWORD}" -Verbosity "detailed" .{PACKAGE}" I get these errors: NuGet Version: 3.5.0.1938 Pushing {PACKAGE}.nupkg to 'http://{MyServer}/nuget/default/'... PUT http://{MyServer}/nuget/default/ BadRequest http://{MyServer}/nuget/default/ 289ms System.AggregateException: One or more errors occurred. ---> System.Net.Http.HttpRequestException: Response status code does not indicate success: 400 (Bad Request). at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode() at NuGet.Protocol.Core.Types.PackageUpdateResource.<>c.<PushPackageToServer>b__19_1(HttpResponseMessage response) at NuGet.Protocol.HttpSource.<ProcessResponseAsync>d__141.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at NuGet.Protocol.Core.Types.PackageUpdateResource.<PushPackageToServer>d__19.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at NuGet.Protocol.Core.Types.PackageUpdateResource.<PushPackageCore>d__13.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at NuGet.Protocol.Core.Types.PackageUpdateResource.<PushPackage>d__12.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at NuGet.Protocol.Core.Types.PackageUpdateResource.<Push>d__8.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at NuGet.Commands.PushRunner.<Run>d__0.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at NuGet.CommandLine.PushCommand.<ExecuteCommandAsync>d__28.MoveNext() --- End of inner exception stack trace --- at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions) at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken) at NuGet.CommandLine.Command.Execute() at NuGet.CommandLine.Program.MainCore(String workingDirectory, String[] args) ---> (Inner Exception #0) System.Net.Http.HttpRequestException: Response status code does not indicate success: 400 (Bad Request). at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode() at NuGet.Protocol.Core.Types.PackageUpdateResource.<>c.<PushPackageToServer>b__19_1(HttpResponseMessage response) at NuGet.Protocol.HttpSource.<ProcessResponseAsync>d__141.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at NuGet.Protocol.Core.Types.PackageUpdateResource.<PushPackageToServer>d__19.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at NuGet.Protocol.Core.Types.PackageUpdateResource.<PushPackageCore>d__13.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at NuGet.Protocol.Core.Types.PackageUpdateResource.<PushPackage>d__12.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at NuGet.Protocol.Core.Types.PackageUpdateResource.<Push>d__8.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at NuGet.Commands.PushRunner.<Run>d__0.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at NuGet.CommandLine.PushCommand.<ExecuteCommandAsync>d__28.MoveNext()<---

That's actually only a display issue with 4.7.10. The endpoint is still /maven2/. We've logged this as PG-1022.

Thanks, I believe this was caused by the anti-virus program. Once I excluded the folder from the scan, the problem went away.

Further troubleshooting seems to have helped. I rebuilt everything on SQL Express 16 instead of the included version 5 included with the installer and everything appears blazing fast at the moment with the more complex setup in place. I'll keep toying with it, but any insight you may have is appreciated. Thanks!