Great! Thank you for the quick response, and also for an excellent lead time. Impressive!

A FileSystemWatcher is used, so any changes to the directory will trigger an import.

Hi Junaid, This is a known issue with npm; basically it's sending a JSON document with two "dist" properties. For example... { "dist": "value1", ..., "dist": "value2" } The JSON Library we're using isn't too keen on that, and we already have a fixe (PG-603) planned/scheduled for the next release.

That was it. The user had access, but not permission to change schema. I really think this should be catch and a nicer message displayed instead of the installer just crashing though.

Hello; I believe the error is due to a bug in the LdapDirectory code, which is not properly escaping that group name that has a parenthesis in it. So, we will need to fix the bug; I've logged this as PG-602, and we can get it in the next maintence release (which is targeted for next week). Best, Steve

Ok, so I have now got something working. It seems it was failing because I had the smaller installer (without sql server). That does absolutely nothing when running the silent command. If that's meant to be the case, then maybe that should be documented somewhere. Thanks

Is there anything listed on the Administration > Error Log page that relates to this? Errors listed there will have additional context (feed, connector, etc) If it doesn't appear there, I guess you could enable 1 at a time to see which one is the culprit.

Ah yes, that solved my problem. Thanks!

We do, along with a few other types (Gems, PyPi, Composer), but there's no ETA on it right now; once we get private a Docker registry, we will look to refactor the feeds and UI a bit as to allow for easier adding of simple package types.

Chocolately packages are, essentially, nothing more than a powershell script that downloads and runs an installer from some url on the internet. It would be virtually impossible to inspect arbitrary powershell scripts and determine what they would download when run, and then download/proxy those installers. So, if you want full control over all aspects of the chocolatey packages (including the installers that are downloaded), you will just have to create your own based on the contents of the open-source packages.

Currently, only NuGet feeds use the license filter, it shouldn't be displayed on npm feeds... We do plan on adding support for better licensing filtering in a future version, as the current implemention is a bit limiting.

OK, I was supposing it but I didn't find it explicitly in documentation. Thanks for your quicker answer.

In ProGet v4.2, there is an option right under Disk Path that says Package Store.

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.