Excellent. Thanks for letting me know, Alana.

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>

It sounds like your load balancer is somehow trying to interact with the Docker protocol in some manner... there's nothing on the ProGet side that should cause that message in the client. It's hard to say, however, given that the load-balancer is forwarding requests to the ProGet software..

Those features shouldn't be available in free versions; if so, that's an oversight/bug.

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.

ProGet already supports SemVer2 for Universal Packages. Unfortunately, NuGet does not yet support this. Remember they also have a "quasi-support" for this quirky 4-party version number as well, which so many packages utilize. Please refer to the NuGet Team's documentation on SemVer. 3.0.0 and up support SemVer 2.0.0 with a limited capacity. Local folders and shares are unable to parse versions with multiple release labels or metadata due to the use of NuGet.Core.dll from the older 2.11.0 client. Project.json restore supports SemVer 2.0.0 and is able to read local folders correctly since it does not depend on NuGet.Core.dll. In some scenarios metadata is written to the disk folder path which causes. Multiple release labels are supported. Starting in NuGet Client 3.5.0-rc1 has added SemVer 2.0.0 for supported for local folders and UNC shares. It's a much more complicated issue than it appears at first, and with the velocity of the NuGet team's releases has slowed, and it's likely NuGet will not fully support this in a while (document was from Oct 2016). We may add some support for this down the line, but it would require a major change to the way we do package indexing, and thus could impact a lot of our enterprise customers. You ought to consider changing your requirement if you're going to use NuGet packages, given the limited supported from the NuGet team for it.

Sorry but I run the indexer and it fails... Creating C:\ProgramData\ProGet\Packages.maven2\I22 if necessary. Opening C:\ProgramData\ProGet\Packages.maven2\I22\next-index.gz to write feed index. Writing local artifact info to feed index. Writing connector http://xcdeveljees2:8081/artifactory/novagalicia-repository artifacts to feed index. Unabled to open Lucene index for connector 31 Index generation complete.

We do not provide a migration utility or tool, but if you create one we would be happy to share it with the community.

You'll need a different path for the ServiceTemp Path. Both Web Site and Service unpack to that directory and load files from there... so there will be a collision.

If you have Windows Integrated Authentication enabled, then it will not be possible to do this. The 401 is occurring before the request even makes it to ProGet, which is how WIA is designed. You can also set up a second site in IIS without WIA enabled. That would lalow the request to get to ProGet, and if you have an "Anonymous" pseudo-user configured with permissions, then the lack of a credential will be ignored.

Thanks, that fixed it.

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

From our development roadmap, at this time there simply is zero interest amongst paying customers (or 98% of free users), so we can't justify the cost of building, documenting, and supporting this, given that we have a lot of other feature requests. However we'd certainly welcome help from the community in making ProGet Windows container ready; please let us know if you'd like to help!!

I think its now implemented: https://inedo.com/proget/versions 5.0.9

Looks like these symptoms are caused when the host goes OOM

Hi Giorgi, Are you using Windows Authentication for your instance of ProGet? Thanks, Jason

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.

This is currently slated for ProGet 4.8-beta, which we expect to release in the next two weeks.