Hi @brett-polivka, We've published v2.0.1 of the Azure extension for ProGet, which should resolve this issue. You can install it from the Admin->Extensions page. Let us know if you are still having the issue after updating the extension. Thank you! -Greg

Thanks for your suggestion, @atripp, that's definitely something we'll look into when we find time to do so. In the meantime we have implemented the workaround described above, so thanks again for your help.

Also: I did remove the second website as we want ProGet to be running on the default web site on port 443 (https).

@gdivis thank you very much.

Hi @pariv_0352, I was able to fix the issue, PG-2160, and it will be released next week on ProGet 2022.2. If you would like to use the fix earlier, you can install a pre-release version of PrGet by installing ProGet 2022.0.2-CI.7 or higher. We have a walk-through on how to install prerelease products in our documentation. Please let me know if you have any questions. Thanks, Rich

Hi @gurdip-sira_1271, I did some more research on this and I think I have been able to reproduce this issue. I have created a ticket, OT-477, to track the fix for this issue. I expect to have this fixed within the next couple of versions of Otter (2022.5 or 2022.6). It is possible that this is an issue with the git extension directly, but I will update you when I have a release date for the fix. Thanks, Rich

Hi @Panda , That sounds like a great idea; I'm afraid we won't have the resources to add this in the coming weeks (we have some really cool stuff planned for BuildMaster 2022 that we're working on now). The easiest way to do local-development on the extension is to get the source code from GitHub, then build it into dll. Then, construct a new version of the Subversion.upack file with your DLL, and replace the one in the existing extensions folder. From there, restart the web/service, and your version should load instead. If you add properties to SvnRepositoryMonitor.cs that look like the other properties, they should show-up in the UI and be configurable. Let us know what you come up with, and we can definitely merge in the code and release a new version with your changes. Cheers, Alana

Hi @bbrown2_8761 , It's a bug in Visual Studio's NuGet client I'm afraid and it's not something we can realistically work-around You could post it in the NuGet issues, and they may fix it in a future version; https://github.com/NuGet/Home/issues It's really easy to reproduce, and they've definitely fixed issues like this in the past. Cheers, Alana

cool, you guys are the best! I've updated the instructions for feeds to make it copy-pasteable for users, rather than having to edit out the options/variables. Naturally I hide the originals and only show the updated ones. Example: the builtin CURL instructions for a package: To download $PackageFullName from cURL, run the following command: curl $DownloadUrl[?contentOnly=[zip|tgz]] --output $PackageName.$PackageVersion.[zip|tgz] --user <user>:<password> I simplified it to: To download $PackageFullName from cURL, run the following command: curl $DownloadUrl?contentOnly=zip --output $PackageName.$PackageVersion.zip Powershell example: To download $PackageFullName from PowerShell, run the following command: Invoke-WebRequest $DownloadUrl[?contentOnly=[zip|tgz]] -Headers @{"AUTHORIZATION"="Basic " + [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes("<user>:<password>"))} -OutFile $PackageName.$PackageVersion.[zip|tgz] simplified: To download $PackageFullName from PowerShell, run the following command: Invoke-WebRequest $DownloadUrl?contentOnly=zip -OutFile $PackageName.$PackageVersion.zip

@atripp got it working without the -e, just using SQL_CONNECTION_STRING for the variable. Thanks for your help!

Hi @ehsan-bahrami91_9979 , This error message is likely related to some sort of proxy server; you can adjust proxy settings under Admin > Proxy. Cheers, Alana

I found the answer , the forwarding headers need to be added to the reverse proxy config when using linux https://docs.inedo.com/docs/https-support-on-linux server { listen 80; listen [::]:80; server_name ""; return 301 https://`$http_host`$request_uri; } server { listen 443 ssl; listen [::]:443 ssl; ssl_certificate /etc/ssl/cert/your_cert_com.crt; ssl_certificate_key /etc/ssl/cert/your_cert_com.key; server_name proget.domain.com; access_log /var/log/nginx/nginx.vhost.access.log; error_log /var/log/nginx/nginx.vhost.error.log; # Disable any limits to avoid HTTP 413 for large image uploads # ProGet requirement for VS to publish to ProGet client_max_body_size 0; # required to avoid HTTP 411: see Issue #1486 (https://github.com/dotcloud/docker/issues/1486) chunked_transfer_encoding on; location / { proxy_pass http://localhost:81; # local server proxy_http_version 1.1; proxy_cache_bypass $http_upgrade; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $http_host; proxy_set_header X-Forwarded-Port $server_port; } }

Hi @aries66_2180, I just set up a clean ProGet 6.0.16 docker instance and tested this and it seems to be working for me. Can you send me an example image you are trying to push that fails? Also, would you be able to use a tool like WireShark or Fiddler to record your requests when trying to push an image and email it over to us at support@inedo.com with a subject of [QA-878] Docker push error? Thanks, Rich

@atripp that's extremely informative! What I found this morning that was deleting and re-adding the connector for the IP feed after clearing the cache(because I'm paranoid) was what needed to happen for it to stop being cached by our Mainline feed.

@atripp Thanks for the reply! I am not aware of any additional pipelines with that same name, but will do some digging and see if I can find it. Thanks for checking.

Thanks for the quick action and the extra information. Did not realise conda build was making the check itself. We're going to install the new version and give it a try. Happy to help and make Proget better

Actually, in our case, broken files are stored in the ProGet storage on a disk, I checked them during the investigation. So it's not an issue that happens on the fly during the download process. And it's also not an issue that happens during package uploading, since after uploading, packages are valid and identical to the original ones on downloading and in the feed's storage. Maybe, those packages were broken in the feed's storage a relatively long time ago for some other reason (a bug in earlier versions of ProGet? a bug in our infrastructure?). And the issue starts to be observable only now because of caches or something like that... At this point, thanks to your answers, it seems that ProGet is not the one to blame. So, I ran a script yesterday that found all the broken packages in the feed, downloaded them from nuget.org, and republished them to ProGet. It was about 100 packages overall. Now I'm sure that every package in our feed is valid. I'll keep monitoring the feed, and if new broken packages arise in the feed, I'll continue the investigation and let you know if ProGet is somehow related to the issue. Thanks a lot, @atripp!

@atripp you're the best. I'll give these a shot and come back if i run into something i can't work through.