I'm afraid we don't have an ETA at this time; we're currently focusing on Debian and PyPi feeds for the moment, and hope to move towards Composer later.

ProGet does not have a "pin version" feature, though it has been requested in the past. Instead, you may just want to create an "archived" feed, and promote packages you want to "pin" to that.

Sure, here they are: ProGet License Agreement Security and Access Controls

Thank you so much for your answer and the confirmation for a futur support of Black Duck. I will contact you once we are ready to work with you (ProGet solution is in planification and installation phasis here). Thanks.

This is available in a standard installation of the latest version under Manage Feed: [image: 6d1pYqr.png] I'll check out the source code now. Thanks.

Well maybe it could be useful to at least integrate into the configuration of the application. This would be a good option if you'd choose that you don't want it to be found in online search results.

I've managed to get this working in v5.0.11 by setting up the second ProGet website in IIS with anonymous authentication enabled and pointing to the same physical path as the original website. The same AppPool is shared between the two and is using the Integrated pipeline. No other IIS or .config configuration was required. In ProGet, for the npm feed that required anonymous access I added the Anonymous user to the feed permissions under Administration > Security > Users & Tasks. Restarting the web services then enabled the anonymous access to the feed using the second website's bindings.

I found a solution. I had to change the pipeline to not restrict the order of the stages.

The error is related to a database connection/query that is timing out. Based on the data you're describing (two servers... not like two million servers), this is the result of network connectivity, or a severe problem on your remote sql server (e.g. other applications consuming all resources).

To resolve this issue, I disabled Anonymous Authentication for the ProGet website in IIS (leaving just Windows Authentication enabled) and restarted all services. I tried this previously to no avail but for some reason it is working fine now.

I'm also getting the same error from ProGet 5.0.10 but reinstalling IIS is not an option. Restarting the service does not make a difference. No web.config customisations have taken place. Server: Windows Server 2016 (14393.1794) IIS: 10.0.14393.0 Authentication: Windows Authentication Windows Authentication Providers: Negotiate, NTLM [SerializationException: Type 'System.Web.HttpContext' in assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' is not marked as serializable.] System.Web.Hosting.ApplicationManager.HostingEnvironmentShutdownInitiated(String appId, HostingEnvironment env) +0 System.Web.Hosting.HostingEnvironment.RemoveThisAppDomainFromAppManagerTableOnce() +156 System.Web.Hosting.HostingEnvironment.InitiateShutdownInternal() +266 System.Web.Hosting.HostingEnvironment.InitiateShutdown() +64 Inedo.ProGet.WebApplication.Pages.Administration.Security.UserDirectories.<>c__DisplayClass8_0.<CreateChildControls>b__2() +597 Inedo.Web.Controls.ButtonLinks.PostBackButtonLink.Inedo.Web.Controls.ISimpleAsyncPostControl.ProcessValidPostAsync() +66 Inedo.Web.PageFree.<ProcessPostAsync>d__61.MoveNext() +400 System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() +31 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +60 Inedo.Web.PageFree.<ProcessPostAsync>d__61.MoveNext() +839 System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() +31 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +60 Inedo.Web.PageFree.<ProcessRequestAsync>d__46.MoveNext() +574 System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() +31 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +60 System.Web.TaskAsyncHelper.EndTask(IAsyncResult ar) +64 Inedo.Web.Handlers.AsyncHandlerWrapper.EndProcessRequest(IAsyncResult result) +33 System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +393 System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) +195 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +128

Hey Thanks for the pointer to the nginx fix, works a treat. Here is my docker-compose setup for anyone looking for a quick and great fix... version: '3' services: proget-web: image: inedo/proget:latest ports: - "888:80" hostname: proget-web restart: always volumes: - "/var/proget/extensions:/var.progetextensions" - "/var/proget/packages:/var/proget/packages" depends_on: - proget-postgres expose: - "888" proget-postgres: image: postgres:9.5 restart: always volumes: - "/etc/localtime:/etc/localtime:ro" - "/var/proget/db:/var/lib/postgresql/data" proxy: image: nginx:1.11 ports: - "2345:2345" volumes: - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro depends_on: - proget-web

No special case. The link to the package statistic indicate 863 downloads and when we click on this link it show us only local package and note what is present in the cache. It's just disturbing. And the statitc on remote package are instrusting as local packages.

I believe the issue is related to the "Execution in Progress Page", which is the "live view" page of the execution, and shows logs like a big textbox. The slowness seems to be more related to client interaction, at least in our exploration. So we have decided to limit this view to previous ~500 entries in v6; you will notice a big improvement for such large log, and can see full details in the details page.

Thanks Dean. The image is available now.

As of V6, we no longer bundle SQL Server. The links should be updated, but they are all the same. There is just one installer now. SQL is now downloaded during install.

Hello Philippe, For restartTimeLimit, I believe StartupTimeLimit and ShutdownTimeLimit (in the Process Model tab for the visual editor) are what you're looking for. I've submitted a pull request to add PeriodicRestartSchedule: https://github.com/Inedo/inedox-windows/pull/35

Hello Lev, A possible reason this might be happening is if Apache is caching the 404 error returned by Docker when the client checks for an existing layer and then returning the cached error after the layer is uploaded and the blob URL becomes valid.