Of course, it's possible that NuGet 3.4 works with your proxy servers differently. I don't know. But in either case, it's most definitely a bug in the 3.4 client; a "nuget push" is a very simple HTTP POST or PUT with a body containing a single file with a multi-part encoding, so if you are getting that error, then no file is being sent (unlikely multiple files). You can use cURL or any other tool to send file to ProGet like that. There is nothing we can change on the ProGet's end to work-around this bug, so please report this to the NuGet team. You should use Fiddler or Wireshark to capture the output from NuGet, and find precisely what requests it is struggling with, so you can share it with them.

Thanks! We will have this fixed in ProGet 4.0.14, which will be released within the hour.

hi @scroak_6473 , just to let you know, as part of ProGet 5.3.10 release, we shipped the ProGetCore container image. You can follow the normal steps in the Linux and Docker Installation Guide to install/upgrade, but just use progetcore for the container instead of proget. Aside from support for the Lucene-based Maven feed indexing (in progress), it seems to be feature complete. And of course, if there are problems, you can switch back to proget:5.3.10 or downgrade as needed (no database schema changes). For example, docker pull proget.inedo.com/productimages/inedo/progetcore:5.3.10 Getting LDAP/LDAPS to work on Linux was a whole different problem to solve; the three major libraries (DotNetCore, Mono, Novell) all had separate and strange bugs. We'll be blogging about this, but for now, it might be a step in the right direction for addressing the problems you're seeing, at the very least.

Thanks I made a backup and ran the script and it did clean up quite a few rows. I'll try upgrading to 2024 again next week after we released :)

Hi Team, Thanks for all your support. I was clearing the temp cache for symbol server. Cleaning up a nuget cache fixes the problem for me. Thanks.

We've finally tracked down what was causing this issue. We had two feeds configured that both had two connectors that connected back to the same ProGet server on different feeds. Turns out that this causes a very high request queue on the ProGet server, which in turn caused timeouts and eventually errors during package restore. I've now created a separate web application in IIS hosting the same ProGet folder but running on a different port and configured those two feeds to connect to the other port. This seems to alleviate the problem for now. Would be nice though if this was supported by ProGet itself. I've seen many artifact repositories that support such a feature where sort of virtualized feeds can be created by combining other feeds.

The reason you have to Get Latest is because otherwise if you built straight from the BuildMaster-managed "ScrRepo" directory, there would be artifacts from the SCM tool also included (for git, .git files), and other times added files from the BuildMaster build steps that you wouldn't want stored with the repo. Once you "Get Latest" somewhere, you can operate on a fresh set of files to perform whatever build tasks are necessary for deployment. Note the "Get Latest" action will essentially perform a clone or pull from BitBucket, then copy the files to the source directory of the action.

@JonathanEngstrom Otter v3 is still really early in the release cycle (closer to what folks used to call "beta" than "stable"), and we're getting the bugs worked out. We also fixed a bunch of bugs (unintended behavior) while testing v3, so it could be an unexpected change. Please let us know specifically what you find so we can look to get things working. I'm not really sure what you mean by "Ensure Server $servername". The only thing you should need to do is change PSEnsure -> PSEnsureScripts to get those scripts working, but the single-script will be a lot better once you get a hang of it. We plan to put a lot of work in documenting this new integration, and coming up with tons of examples to help folks verify the configuration and configure their servers. The main real advantage to the new PSVerify/PSEnsure mechanics is that you can write a single PowerShell script to both verify and configure servers, and more easily create/modify/test/share those scripts outside of Otter.

Hi @hwittenborn, Thanks for the additional information. We talked about this in our team meeting this week and we decided we are going to clean up when restarts are needed and we are hoping to give better messaging to the user when a container needs to be restarted. Some of the restart requirements are leftover from previous requirements that have since changed. So hopefully we can make this process a bit easier in the future. Thanks, Rich

That's correct in that it's too early to read the file, which is why it results in the sharing violation (the file is opened for write by w3wp.exe without FileShare.Read). The new file in the directory triggers the FileWatcher (which doesn't find the file because it's not completely written yet). However, the NotifyChangeDirectory operation in the feed directory will trigger the FileWatcher again after the file is completely written and closed in which case it would get picked up by the indexer, and that would make the package appear in the feed. Is there a way to run the monitor again to cross-reference the times that the error appears in the ProGet error log with a violation within the Process Monitor log? I am thinking that these particular sharing violations are not related to the errors you're seeing.

Hi @devopsdude3113, What scopes do you have configured for your personal access token? When I tested this, I created a personal access token and added only the read:packages scope. Also, do you see any error in your ProGet diagnostic center? Thanks, Rich

@atripp said in Still cannot push Windows Docker image to ProGet: install an intermediate tool, like Fiddler or Wireshark, to capture traffic from your workstation. Maybe the raw traffic will give you a better clue. Hey. No errors that seem relevant in the Diagnostic Center. I'll try to set up Fiddler and see if I can go from there.

Gitlab offers too many options/features we don't need (CI/CD, Kubernetes, Promotheus etc ....). This is why I was looking for a more lightweight Git repo I was previously using BonoboGit on Windows which a very basic Git repo but good enough for our need. As the webhook is not possible, I am looking to replace it. I think we will stay on GitLab CE - everything is working and I can't spend my time to evaluate all the possible software, I have to pick one and use it.

@philippe-camelio_3885 FYI, we will add a checkbox for auto-purging soon, BM-3655

@v-makkenze_6348 said in Reporting & Software Composition Analysis (SCA) shows many unresolved Issues: I repackaged the Owin package but didn't relalize that that would break all my builds as the dll's are now in a 1.0.0 folder where all the project files expect them in the 1.0 folder. I guess this would work if the projects are in sdk project format but most of them are not. Unfortunately, a consequence of those quirky versions. Hopefully it won't be too bad to update those projects/references with a bit of search/replace :)

SOLVED See the following Stack Overflow question fro the solution. http://stackoverflow.com/questions/3853767/maximum-request-length-exceeded In summary: in the web.config <configuration> <system.web> <httpRuntime maxRequestLength="2147484" /> </system.web> </configuration> and <system.webServer> <security> <requestFiltering> <requestLimits maxAllowedContentLength="2147483648" /> </requestFiltering> </security> </system.webServer> Note: maxAllowedContentLength is measured in bytes while maxRequestLength is measured in kilobytes, which is why the values differ in this config example. (Both are equivalent to 2 GB.)

Hi Tod, sorry my falled your workaround is working thx

Hm, anything is possible, but I have seen a custom API endpoint causing problems, and a one without privileges set for an API key. Perhaps you can explore the code a little, to see what might be an issue? It's basically just simple HTTP calls to various URLS using Basic HTTP authentication: https://github.com/Inedo/bmx-jenkins/blob/master/JenkinsClient.cs

Not yet; I saw an internal presentation on it, but I don't know the communication plan. Feel free to check with @apxltd directly... email or slack seem to be best ;)

Finally got it working, turns out a single quote at the start and end of TextData is enough for the configs to be fully included without error, while still accepting BuildMaster parameters, Here's the code in case there is a desire to implement Job creation in the Jenkins extension, (anonymized a little): Post-Http http://Jenkins:8080/job/TestNewAPIJob/config.xml ( ContentType: application/xml, TextData: '<?xml version="1.0" encoding="UTF-8"?><project> </project>', LogRequestData: true, LogResponseBody: true, RequestHeaders: %(Authorization: Basic xyz123) ); Thanks for the help getting this going, this was my first time using 5.3 from 4.7, little learning curve with the new Plan editor that is really cool! -Dan