When this build finishes, docker pull inedo/proget will fix the issue with special characters in the database password: https://hub.docker.com/r/inedo/proget/builds/bi8ds7thvriyfldkbh2daj6/

Integrated Mode is correct for newer versions of our products - sometime between now and then it changed from classic to integrated. I'll put in a note to fix that in the docs.

Thanks Ben that did the trick :-)

Hi Ben Lubar, The error messages are listed as follows: Add new ADUserDirectory.sql failed: 42601: syntax error at or near "IF" Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object at System.Web.Caching.Cache.ExpireItems (System.Object data) [0x00008] in <d777bf5120224d38839a5bae355ed440>:0 at System.Threading.Timer+Scheduler.TimerCB (System.Object o) [0x00007] in <77c9551943624fd18301ba6f78a841e5>:0 at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () [0x00008] in <77c9551943624fd18301ba6f78a841e5>:0 at System.Threading.ThreadPoolWorkQueue.Dispatch () [0x00074] in <77c9551943624fd18301ba6f78a841e5>:0 at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () [0x00000] in <77c9551943624fd18301ba6f78a841e5>:0 [ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: Object reference not set to an instance of an object at System.Web.Caching.Cache.ExpireItems (System.Object data) [0x00008] in <d777bf5120224d38839a5bae355ed440>:0 at System.Threading.Timer+Scheduler.TimerCB (System.Object o) [0x00007] in <77c9551943624fd18301ba6f78a841e5>:0 at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () [0x00008] in <77c9551943624fd18301ba6f78a841e5>:0 at System.Threading.ThreadPoolWorkQueue.Dispatch () [0x00074] in <77c9551943624fd18301ba6f78a841e5>:0 at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () [0x00000] in <77c9551943624fd18301ba6f78a841e5>:0 Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object at System.Web.Caching.Cache.ExpireItems (System.Object data) [0x00008] in <d777bf5120224d38839a5bae355ed440>:0 at System.Threading.Timer+Scheduler.TimerCB (System.Object o) [0x00007] in <77c9551943624fd18301ba6f78a841e5>:0 at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () [0x00008] in <77c9551943624fd18301ba6f78a841e5>:0 at System.Threading.ThreadPoolWorkQueue.Dispatch () [0x00074] in <77c9551943624fd18301ba6f78a841e5>:0 at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () [0x00000] in <77c9551943624fd18301ba6f78a841e5>:0 [ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: Object reference not set to an instance of an object at System.Web.Caching.Cache.ExpireItems (System.Object data) [0x00008] in <d777bf5120224d38839a5bae355ed440>:0 at System.Threading.Timer+Scheduler.TimerCB (System.Object o) [0x00007] in <77c9551943624fd18301ba6f78a841e5>:0 at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () [0x00008] in <77c9551943624fd18301ba6f78a841e5>:0 at System.Threading.ThreadPoolWorkQueue.Dispatch () [0x00074] in <77c9551943624fd18301ba6f78a841e5>:0 at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () [0x00000] in <77c9551943624fd18301ba6f78a841e5>:0 I hope this help.

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

It would be the Windows Event/error Logs, specifically the Windows Service Manager. If ProGet isn't able to run/load, then it wouldn't be able to log anything.

Jon I've run into the same issue before dealing with the npm feeds. I ended up hosting the proget site twice in IIS under different hostnames. In IIS we have two websites: proget.mycompany.com Windows Auth enabled Forms Auth disabled Anonymous Auth disabled formsauth-proget.mycompany.com Anonymous Auth enabled Both sites use the same physical path of your proget installation. The host name in the binding must be different though. That is so IIS knows which way to go, the website with Windows auth or the site with the anonymous auth. We've been using this for several months with no problems. I hope it helps in your situation. Please note, I do not work for ProGet, I'm a fellow customer offering assistance.

While you are able to specify multiple domains and credentials to those domains, you would have to try it and see. It all really depends on your configuration. Fortunately you are able to create your own user directory, and you could probably just simply use code from the Active Directory (new) and modify it to suit your needs.

Could you capture a Fiddler or WireShark trace of the ProGet response? There should be an error message associated with the 400 (either There must be exactly one package., which would indicate a proxy issue or Package validation failed: followed by an error message, although from a quick glance over the source code, I don't see how that could happen for a NuGet package.) Another possible cause is an IIS module, like WebDav, intercepting the request before it gets to ProGet.

I think I got it working. The documentation is really lacking and hard to find. After hours of searching I found https://inedo.com/support/kb/1112/api-keys-in-proget page. First I had to drop anon permissions to "Publish Packages" (I think it may have been off by default). Add a new task (e.g. "Publish to feed") and select the following operations: Add package Overwrite package View feed Grant anon user permissions to the new task Set an API key for the target feed and use the key in my CI/CD pipeline

Hello Tore, I've fixed the 'syntax error at or near "IF"' error for future versions of ProGet on Linux, but that specific change script failing should not cause any problems. If you want to use the new AD user directory, you can add it on /administration/security/manage-directories. I've filed the missing ChunkedUploads_* functions as PG-1142. They are missing from the Linux version of ProGet. I'll check to see if any other functions are missing.

Yes, it's available. You will need to associate the licenses with a "known" license type that is allowed. Many NuGet packages ship with proprietary licenses, or licenses that point to "random" URLS (like GitHub.org/project-name/license.txt) instead of a "known" OSI URL. This is why they are considered "unknown" to ProGet.

It's not currently supported, but we'll consider doing it through the API or CLI at some point.

This is supposed to check every hour. If it's not, sounds like the service's task runner isn't running. Just restart the service, then its should be ok.

Hello Stijn, This issue is caused by a hidden version of the package: https://www.nuget.org/packages/Swashbuckle.AspNetCore/1.0.0--rc1. I've filed this as PG-1146 and will submit a fix for my co-workers to review.

This is the nature of connectors; if npm client asks for "latest" version, then all connectors need to be searched. If you don't want behavior, then you need to remove connectors that have newer versions.

The situation with Azure is a bit confusing; I will put a note in to the docs team that it should support asset storage, but it can not support large/chunked uploads because of the limitations of the blob storage API that Alana mentioned.

Hi, i'm running into this now in Version 5.3.17 (Build 19). All of our packages are internal use only and i don't want to bother with setting up license rules. Can i disable the license checking?

This would require writing a custom package store. The disk-based package store does not support this. Perhaps consider using Connectors, or something like that

Hi Alana, Thanks its working fine now.