Hi @shiv03_9800 , thanks for the detailed report on these! We've identified these as OT-440 and OT-441, and they will be fixed in the next Otter maintenance release (3.0.14), scheduled for tomorrow. Cheers, Steve

Thank you for your fast response. Just updated to 6.0.2-ci-3 and it is fixed

@harald-somnes-hanssen_2204 unfortunately not; a feed index provides details about only the latest version of a package. You need a separate query to find details about all versions of a package, and then would need to do that query for each package in an index Instead, it's better to just have a feed of approved packages that developers could use. This will let you also filter for other problems like quality. We recently published some advice about, but it's for nuget feeds. https://blog.inedo.com/nuget/package-approval-workflow It would work the same way for npm though

@Stephen-Schaff We're also considering locking down nuget.org, so the more info we have in ProGet, the better.

@Dan_Woolf, Thanks. This will help me a lot.

Thanks Nanci for your response. I exactly don't know how variables are being passed from one step to the other in same block of code to the other. Otter script documentation is not so clear on it. I have created separate thread fore that. If you can answer that. Setting Runtime Variable From Powershell Script Thanks

@gdivis Thank you very much (it works).

Hello, This is unfortunately due to bugs in the PowerShellGet & PowerShell Gallery API that aren't feasible to workaround. Basically, the API is reporting different versions than the package file, which makes working with local/cached packages and remote packages painful like this. However, it seems like it's going to be addressed by Microsoft, finally, in PowerShellget v3. In any case, given your architecture (i.e. "Machines on our network cannot connect to PSGallery direct due to the firewall and are only allowed to retrieve via this one feed."), we recommend using a Package Approval Workflow instead. create an 'unapproved-powershell' and approved-powershell feed create a connector on 'unapproved-powershell' to PSGallery.org Promote packages from unapproved-powershell to approved-powershell This will totally eliminate the "bad API" problem as well. Cheers, Alana

Hello Alana, Yes my first guess was also application Pool shutdown and wakeup. Thats not the problem as the website will stay slow all the time. Also its reproducable that two browsers on the same machine work with completly different speed. I will provide logs of the page you mentioned when i run in that problem again. Clearing cache did reproducable solve the problem. Of course the first call might take a second longer, but after that it works fine. Best Regards Dario

@forcenet_4316 great, sounds good! Actually we didn't end up shipping 6.0.0 yet (we will soon), so I just changed PG-2011 to target 5.3.40, which is scheduled for release on Friday. This way it will be in both.

Thanks @drew-stinnett_4680 ! I've updated the documentation with a link to this discussion.

The error is generic and there are many reasons why the SSL/TLS negotiation may fail. ServicePointManager.SecurityProtocol property selects the version of the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol to use for new connections; existing c# connections aren't changed. Make sure the ServicePointManager settings are made before the HttpWebRequest is created, else it will not work. Also, you have to enable other security protocol versions to resolve this issue: ServicePointManager.Expect100Continue = true; ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 SecurityProtocolType.Tls SecurityProtocolType.Tls11 SecurityProtocolType.Ssl3; //createing HttpWebRequest after ServicePointManager settings HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/") If you create HttpWebRequest before the ServicePointManager settings it will fail and shows the error message.

It seems that PowerShell client doesn't provide much details about errors, so glad you could figure out what the issue was for powershellgallery.com. That message probably could mean a lot of things, and is probably unrelated to TLS/SSL.. So the first thing that's jumping out to me is this: WARNING: Unable to resolve package source 'http://proget.domain.org/nuget/ps' There is no https connection, so there'd be no TLS/SSL issues. But assuming you may have changed the url when posting this... here is a registry key you can use to force that setting (it makes that powershell command unnecessary) https://inedo.com/support/kb/1161/tls-v12-configuration-and-connection-errors If you're on HTTPS the other thing to look at would be certificates. Otherwise, you may need to use something like Fiddler to see the actual request/responses that PowerShell client is issuing/reciveing.

Hi @jan_ko , Thanks for sharing this; the .nuspec file looks okay to me, so it doesn't seem like a problem with the package. After building the agent pushed these nupkg's to the Azure DevOps Artifacts. This feed is connected to a ProGet connector. Well, I'm thinking the issue is in the Azure DevOps Artifacts API. We found many bugs in their feeds already (i.e. not implementing the API as specified). It happens to work in Visual Studio, or Visual Studio already worked around the bug. We can spot it very easily with a debugger; if you can share to use a feed url and credentials (I think it's just n access token?), then we can connect to the feed and see what's causing that error. You can send us the details via the ticket, so then it's not public. Cheers, Alana

Hi @philippe-camelio_3885, This has been fixed and will be released in Otter 3.0.13 which is expected to be released on October 22nd 2021. Thanks, Dan

Hi, This is an old thread but i have the same question. We're on 5.3.17 and have used up all of the space on C:\. We have 1TB on D:\, so I just want to move the PackagesRootPath to there. Does the above pattern still apply? thanks max

Hi @Stephen-Schaff, The latest tag is a bit odd. Each client handles it differently and I have found most clients will not repull a newer version if latest has already been pulled once. According to Docker's API (and Kubernetes), a client is supposed to pull the manifest from the server and compare it with the currently downloaded image and update if there is any difference, but I have found that does not always work. You can configure Kubernetes to always pull an image, but I cannot confirm how well it works. As for getting a list of tags, we basically have two ways. What it sounds like you are looking for is to just get a list of alternative tags. The only way to do this is to use our native API and using the DockerImages_GetTags method and grouping by DockerImage_Id. The other way to get a list of tags would be to use the docker API itself. This way will get all tags associated with a repository, not just the alternative tags. To do this: Make a get request to http://<your proget server>/v2/_auth with an Authorization header with the value of Basic <BASE 64 encoded username:password> The response will be a JSON object. Take the value in the token property Make a GET request to list all tags to http://<your proget server>/v2/<feed name>/<image>/tags/list (ex: `http://proget.localhost/v2/defaultdocker6/dotnet/core/aspnet/tags/list) In the header include an Authorization header with a value Bearer <token from step 1> This will return a JSON object that has an array property called tags That will get you a list of tags using the Docker API. Hope this helps! Thanks, Rich

Hi @shiv03_9800, We have just released a new version of Otter that includes a fix for the segmentation fault. You will need to make sure that .NET Framework 4.5.1 or greater is installed on the Windows server. But if you were able to run the Inedo Agent installer, then chances are you already have that installed. As for the Inedo Agent error, I talked with some colleagues and this is something we have seen on slower or congested networks when checking Inedo Agent has the components needed to communicate with Otter. Normally if you wait for the next server check to occur, the issue ends up resolving itself. There was another issue, however, that can affect PowerShell scripts when using the Docker version of Otter, OT-432. This was fixed in the latest release as well. Thanks, Rich

If you are using IIS for hosting your application, then the default upload file size is 4MB. To increase it, please use this below section in your asp.net web.config - <configuration> <system.web> <httpRuntime maxRequestLength="1048576" /> </system.web> </configuration> For IIS7 and above, you also need to add the lines below: <system.webServer> <security> <requestFiltering> <requestLimits maxAllowedContentLength="1073741824" /> </requestFiltering> </security> </system.webServer> Note: maxRequestLength is measured in kilobytes maxAllowedContentLength is measured in bytes