Thanks; we've identified a possible race condition during initialization, specifically involving discovering the connection string of the currently installed instance. We've made a small code change which should resolve this issue - assuming it is the cause. We haven't been able to reproduce it on our systems. The installer for the next version (which should be 3.6.2) will have the fix, so you may want to try using the larger installer again just to see if the issue goes away. You never need the full installer to perform an upgrade, however.

This was fixed in ProGet v3.6.2, thank you again for the report.

Most definitely not. Unfortunately, we have no idea when NuGet v3 will come out, nor do we know when/if there will be API docs availalble (or a stable codebase to reverse engineer the API). Based on the various iterations of the v3 API that have been published in preview/beta, we have little confidence that it will solve the performace problems that ProGet users experience with connected/remote packages; so, on the ProGet Roadmap, we plan on solving that by creating a full index of nuget.org. That said, the NuGet team will need to support v2 for several years to come, so we're in no rush. Moreover, We have a plan that http://inedo.com/support/questions/3130

That sound like a good solution!

As long as the Global Catalog can search the other forest it should work, if there is a restriction on that, then it will not find the user. By default however, it uses the Forest.GetCurrentForest() to determine which GC to query. We are now planning to make some improvements to the way authentication works as it is slowly becoming the #1 requested feature/improvement.

See: http://inedo.com/support/questions/3090

Thank you very much guys for pushing this feature to the last release. I've upgraded our server today, turned the option on, and it works great. Cheers.

Actually I was able to repro this (only when LDAP is enabled however); thank you for the report - it will be fixed in the next maintenance release v3.6.2. As a workaround, just visit the /administration/feeds/select URL directly.

Thank you for the additional information, we were able to reproduce. The fix will be included in v3.6.2. If you want an immediate patch for v3.6.1, you can download the file at: http://44.inedo.com/proget/NuGetPackageVersionPage.js and save it into the WebApp directory of the ProGet installation under the following subdirectory: WebApp\Resources\mapped\Pages\NuGet\Feeds\ alongside the NuGetPackageVersionPage.js.gz file. You may have to clear your browser cache to see the change.

npm changes its access URLs a lot, and from looking through its checkin history it usually seems to be accidental. ProGet currently supports two URLs for adduser: /-/user/org.couchdb.user[...] or /npm/[FEED]/-/user/org.couchdb.user[...] I've never seen any version of npm use a ~ instead of a - before... What version did you upgrade from?

You may be best asking this on NuGet forums, as this relates to behavior in the nuget.exe client. We do not use "nuget.exe pack" ourselves (instead, we opt to use the proget client tools) as it's more reliable and has defined behaviors.

It is also worth noting that strictly speaking, pushing packages does not require the View privilege, that is a result of the NuGet client sending a GET request (i.e. "list") first before sending the PUT request to push the package -- it's the first request that gets 401ed. You can use the following PowerShell script to perform just the package upload: $FeedUrl = 'http://proget/nuget/Default' $FileName = 'C:\tmp\ProGet\packages\Package.1.0\Package.1.0.nupkg' $APIKey = 'Admin:Admin' #params([string]$FeedUrl, [string]$FileName, [string]$APIKey) $req = [System.Net.WebRequest]::CreateHttp($FeedUrl) $req.Method = 'PUT' $req.ServicePoint.Expect100Continue = $false If ($APIKey) { $req.Headers.Add('X-NuGet-APIKey', $APIKey) } $boundary = '---------------------------' + [System.Guid]::NewGuid().ToString('n') $req.ContentType = "multipart/form-data; boundary=""$boundary""" $utf8 = New-Object -TypeName System.Text.UTF8Encoding -ArgumentList ($false) $reqWriter = New-Object -TypeName System.IO.StreamWriter -ArgumentList ($req.GetRequestStream(), $utf8) $reqWriter.WriteLine("--$boundary") $reqWriter.WriteLine("Content-Disposition: form-data; name=""package""; filename=""package""") $reqWriter.WriteLine("Content-Type: application/octet-stream") $reqWriter.WriteLine() $reqWriter.Flush() $fileStream = [System.IO.File]::OpenRead($FileName) $fileStream.CopyTo($reqWriter.BaseStream) $fileStream.Close() $reqWriter.WriteLine() $reqWriter.Write("--$boundary--") $reqWriter.Dispose() $response = $req.GetResponse() $response.Dispose()

We have not had other users report this problem, nor have we seen it during testing. You can try running the service interactively (just stop the WIndows Service, then run the .exe file), and see what happens. Also worth noting, make sure that all the errors in the log are deleted before the packages start indexing again.

ProGet works great with NuGet client v3! As far as the "protocol" is concerned (i.e. ODATA vs JSON-LD) the "v3" protocol is intended only for use by nuget.org and nuget client. It's not documented by Microsoft, unstable, and they have no plans to document or support it. Since the "v2" protocol (ODATA) works just fine, we are not going to reverse engineer the "v3" protocol or otherwise use it.

Thanks for the help investigating this. We've identified a possible race condition during initialization, specifically involving discovering the connection string of the currently installed instance. The presence of .NET 2 shouldn't affect things, as the installer specifically targets 4. The 20 in the CLR20 error just refers to the runtime version. .NET 4 runs on the CLR 2.0 runtime, confusingly enough. We've made a small code change which should resolve this issue - assuming it is the cause. We haven't been able to reproduce it on our systems. The installer for the next version (which should be 3.6.2) will have the fix, so you may want to try using the larger installer again just to see if the issue goes away. You never need the full installer to perform an upgrade, however. Again, thanks for the help!

If you're seeing this message, then you'll need to ensure ASP.NET4 is installed -- not just .NET4 and .NET4 Extensibility. It's a separate option (that's kinda hidden).

You will need to use Fiddler to determine the EXACT urls that are causing a problem during package restore; we can then investigate what query is causing the problem.

I can't believe I missed that. I upgraded and that problem is gone but with new issues. Will open a separate question for that problem. Suggestion: How about adding a new tag npm? Thanks Niklas

This error means that the connection string in the installed product doesn't work for the user installing the software. Most likely, you don't have access to the database or server. I think the discussion here http://inedo.com/support/questions/3126 may be related as well.

The basic process is: Install the exact same version of ProGet on the new machine Backup the ProGet the database and restore it onto new machine over the new database that was created by the installer Set a bulk import path for each feed Copy the packages from each feed into the corresponding bulk import path of each feed Allow a minute or so for the indexer to pick up the new packages and add them to the feed