In ProGet v4.2, there is an option right under Disk Path that says Package Store. [image: vYDcll0.png]

Here are the exceptions that I'm getting when add my extension(nothing descriptive for me): Details: URL: http://localhost:81/administration/extensions Referrer: http://localhost:81/administration User: Admin User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko Stack trace: at System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6.FlushCore(Byte[] status, Byte[] header, Int32 keepConnected, Int32 totalBodySize, Int32 numBodyFragments, IntPtr[] bodyFragments, Int32[] bodyFragmentLengths, Int32 doneWithSession, Int32 finalStatus, Boolean& async) at System.Web.Hosting.ISAPIWorkerRequest.FlushCachedResponse(Boolean isFinal) at System.Web.HttpResponse.Flush(Boolean finalFlush, Boolean async) at System.Web.HttpWriter.WriteFromStream(Byte[] data, Int32 offset, Int32 size) at Inedo.IO.SlimMemoryStream.CopyTo(Stream destination) at Inedo.Web.PageFree.SimplePageBase.ProcessRequest(HttpContext context) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) And another one: URL: http://localhost:81/administration/error-log/entry?messageId=139 Referrer: http://localhost:81/administration User: Admin User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko Stack trace: at System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6.FlushCore(Byte[] status, Byte[] header, Int32 keepConnected, Int32 totalBodySize, Int32 numBodyFragments, IntPtr[] bodyFragments, Int32[] bodyFragmentLengths, Int32 doneWithSession, Int32 finalStatus, Boolean& async) at System.Web.Hosting.ISAPIWorkerRequest.FlushCachedResponse(Boolean isFinal) at System.Web.HttpResponse.Flush(Boolean finalFlush, Boolean async) at System.Web.HttpWriter.WriteFromStream(Byte[] data, Int32 offset, Int32 size) at Inedo.IO.SlimMemoryStream.CopyTo(Stream destination) at Inedo.Web.PageFree.SimplePageBase.ProcessRequest(HttpContext context) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

If it's showing up on the one page, but not the other, then i'd say it's definitely a bug. I've logged as PG-595, so we will look to fix in next maintenance version.

Please refer to the ProGet Silent Installation page.

If you're able to get it up and running, then we'll definitely support as per usual. Basically we just don't have the knowledge/expertise to help install / set-it up on Azure (we haven't even tried it ourselves). But it should work... they seem to support a lot more parity with regular SQL Server, and a lot of installs are on SQL Azure.

This is not currently supported, though we will look to add this in a future version. pguinstall.exe was never intended to be run by another process, or run silently, etc. It's only meant to be called interactively, via the "Remove Programs" dialog. We will look to add an uninstall script in a future version, but for now this isn't supported. You could always write a simple powershell script, and remove the service, webapp, and installation directory. That's pretty much all that is installed.

As of v4.2.0, the ProGet Chocolately package does not have an uninstall script. At the time we build the package, the uninstall scripts were not at all in common use or recommended. However, in the latest version of Chocolately, it seems the client inspects the registry to see what was added to the "remove programs" keys, and then attempts to run the commands. Like most "uninstallers", pguinstall.exe was never intended to be run by another process, or run silently, etc. It's only meant to be called interactively, via the "Remove Programs" dialog. We will look to add an uninstall script in a future version, but for now this isn't supported.

The error you shared was: An error occurred processing a PUT request to {url}: Invalid user name or password. A PUT request is what the NuGet client does to push packages to a feed. You'd want to look for a message related to GET or other requests. But, if you're seeing an unknown, then the problem is likely authentication related, but you'd have to look in the error log, it could be a bad url too... You can always try run fiddler, and attach ProGet to the fiddler proxy server to see precicely the requests that proget is making as well.

If the feed is reporting "healthy" that means that an initial check passed. The 500-status errors will be logged on Admin > Error Logs; without seeing those, it's not really possible for us to advise on what the issue is. Hopefully that will give insight as to what could be failing. You may need to attach a proxy server between ProGet and MyGet (e.g., install Fiddler on the server, then point ProGet to use the Fiddler proxy), in order to capture the traffic.

I updated the default schema on the security group I was using to dbo and I was able to run a successful install. Thank you!

After upgrading both the ProGet VM and our (potentially underpowered) Active Directory VM to more cores/more RAM, we seem to have worked around the issue. Thanks for the tips!

ProGet is designed for enterprise/organizational package management, and this is simply not a requirement or desired at all in those environments. So, it's highly unlikely we will add first-class support for this. Some organizations have created custom user directories for this purpose, which is possible with the SDK. Note: if you are a component company, you may want to contact us to see about partnering. We work with a handful of component vendors who use ProGet as a "back/middle-end" and then have a very simple customer-facing front-end on top of ProGet that integrates with their CRM, authentication, etc.

This is not currently supported. If you are a component company, you may want to contact us to see about partnering. We work with a handful of component vendors who use ProGet as a "back/middle-end" and then have a very simple customer-facing front-end on top of ProGet that integrates with their CRM, authentication, etc.

We just updated our server from 4.0.8 to 4.2.0 and now we encounter this problem too. After confirming that the package/version should be deleted, you are redirected back to the feed but the package/version is still there. In the log there are no errors whatsoever and the recent error log shows "There are no recent errors."

The Jenkins / ProGet Plugin has been updated to Version 0.3 with the following changes: Expand variable correctly Some basic validation on the version number If you update, then it should work!

i updated to PowerShellGet 1.1.1.0 and it solved my issues. Release Notes PowerShellCore support Security enhancements including the enforcement of catalog-signed modules during installation - Authenticated Repository support Proxy Authentication support Responses to a number of user requests and issues

This was a regression in 4.1.2, but it is fixed now in 4.1.3.

angular-cli gave me problems. It tries to retrieve dependent packages from https://registry.npmjs.org. ( https urls don't works on our dev pc's) At the moment I also configured the server with the feed as my proxy server, so at least that traffic passes over this server for all package handling. (I also have github and such) Tnx for any info you can provide Stijn

Can you share both the .nuspec and packages.config file? That would help quite a bit.