You can look in the Web.config file in the ProGet Service directory to see what connection string it is currently using to connect to the database. If you installed everything with default settings, this will be using integrated authentication, so it's connecting using whatever account the ProGet Service is running as. Outside of this, whoever installed/updated ProGet last would have also needed to have access for integrated auth.

This isn't currently exposed in the UI, but you can run this SQL query against ProGet's database to get a list of cached packages in a NuGet feed: SELECT * FROM [NuGetPackages_Extended] WHERE [Cached_Indicator] = 'Y' AND [Feed_Name] = 'MyFeedName'

Hi Mark, We just sent you an email with a stop-gap license. Please let us know if you don't get it.

That's actually supposed to be cached, but due to a bug it looks like it's only cached if there is not a timeout when trying to download the news. We'll get that fixed in a maintenance release; thanks for letting us know!

This is not a known problem on the server-side of ProGet, but instead a problem on the client; that "Stream" is referring to something opened on the client, and closed on the client. We've also seen similar behavior with some 2.8.x versions of NuGet.exe, and perhaps OD shares some of that code?

Sorry about the broken link! That article has be updated and that link should now redirect to the correct page: http://inedo.com/support/documentation/proget/feeds/nuget/visual-studio-extension

Now that the current version of Visual Studio seems to respect authentication challenges, we are adding support for this. The tracking issue is here: PG-1273

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.