ProGet will not give this error code, so it's coming from another tool/service in between NuGet.exe and ProGet software. Please disable WebDAV, and any other things sitting in front of the ProGet server that would issue a 405 before relaying the request to ProGet.

It's certainly planned on our end, but because it would require a major change to the way we do package indexing, which is a significant risk and thus could impact a lot of our enterprise customers.

Nevermind, I had to grant the Feeds_AddPackage privilege to the Anonymous User.

Ah ha! Thank you so much. I'll look in to this right now :)

I would remove the "NuGet API Key" from your NuGet feed; that is a seperate thing from "ProGet API Keys", which makes it quite confusing. This is why it will be deprecated in v5. You don't need an API key; you can just publish using usename/[password.

As far as we can tell, ProGet has never returned a 409 response from that endpoint. A quick Google search reveals this NuGet bug: https://github.com/NuGet/Home/issues/2910 You can fix this by upgrading to NuGet.exe 3.4.5, NuGet.exe 3.5.0-beta2, or a later version.

To solve this, make sure to have the following nuget.config file in the same dir as the .sln file. <?xml version="1.0" encoding="utf-8"?> <configuration>   <packageSources>   <clear />   <add key="ProGet" value="https://your-proget-server/nuget/feed-name/" protocolVersion="2"/>   </packageSources> </configuration>

Unfortunately, no, I was not. I'm in the process of taking a look at ProGet running in containers again, I will test in the near future and let you know. I don't expect it to be working unless something changed with the containers in the last several months.

This was a breaking change NuGet team made in NuGet 3.4 (I think). We did not want to not implement, as the change would impact a lot of our customers who rely on the quirks of "non-normalized" versions. So, as a compromise, the NuGet team implemented a searching strategy in the client to try a normalized version of the number (like 0.0.0.0), and then try non-normalized version (0.0.0) if not found. At this time, you'll need to do the same for your searches; if we ever decide to implement the normalized version, this strategy will be backwards compatible.

I created a ticket with Paket, and they did resolve the issue via an update to their code base. Testing with version 5.6.6 seems to have fixed the issue. https://github.com/fsprojects/Paket/issues/2466

If you are using a newer version of MSBuild, see: http://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html If you are stuck with an older version, the solution is specific to whatever CI server you're using, e.g. with BuildMaster you would use the NuGet::Install-Packages operation; with TeamCity you would use the NuGet Installer build runner, and so on.

If you want to quickly add something like this are familiar with C#/.NET you can already create a custom package store to do this, see: Extending ProGet Beyond that, we will consider this as a first-class feature as you suggested. If you have any specific thoughts as to what would need to be configured for the hooks please add them to this thread.

Hi Alana This page (https://inedo.com/support/documentation/proget/core-concepts/connectors) has no info that I have to link the connector to my feed. Just add a little section at the end with a screenshot so the users sees what he has to do after creating the connector.

Hello Tom and Brett, The endpoint being requested seems simple enough. For example, here's what it requests for -StartWith Inedo.. I've filed PG-1281 to add an implementation of this endpoint.

Never mind, found the 5.0 beta :-)

Hey Thanks for the pointer to the nginx fix, works a treat. Here is my docker-compose setup for anyone looking for a quick and great fix... version: '3' services: proget-web: image: inedo/proget:latest ports: - "888:80" hostname: proget-web restart: always volumes: - "/var/proget/extensions:/var.progetextensions" - "/var/proget/packages:/var/proget/packages" depends_on: - proget-postgres expose: - "888" proget-postgres: image: postgres:9.5 restart: always volumes: - "/etc/localtime:/etc/localtime:ro" - "/var/proget/db:/var/lib/postgresql/data" proxy: image: nginx:1.11 ports: - "2345:2345" volumes: - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro depends_on: - proget-web

You may have a proxy server that doesn't allow a connection to Inedo.com; that's where latest news is loaded from. There's not enough to help here.

It seems like something changed in security settings - Publish Packages task got "private" scope. [image: vo6hmcg.png] I droped "Publishers" and added them again, scope has been changed to "all feeds" and problem gone! [image: NEDd3NU.png] Seems it's an upgrade bug because the scope option can't be set in free version... [image: 8qyYRQ3.png]

The default PDB format for the project files was changed from Full to Portable (see https://github.com/dotnet/core/blob/master/Documentation/diagnostics/portable_pdb.md). The portable format is not compatible with the symbol server. To switch back to the old format just add this to a property group in the *.csproj file: <DebugType>Full</DebugType>. You can also override this with /p:DebugType=Full in your build command. Also make sure that the nuget packages are created with --include-symbols --include-source

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()<---