Try LongPathTool for this problem

Hello; this issue is known now, I've logged an issue and we'll get it fixed in the next release; PG-1727 Release is scheduled for Friday, but we may ship it sooner.

@rhessinger Thanks a lot. I will try it.

Sounds neat, we'd love to learn how you have it set-up! This is the first request for this, and like all feature requests, we want to make sure we can document it well. So I wonder, can you think of a way to improve our documentation with an example of your Stack File, and some mention how you're suing docker swarm to monitor things? Maybe as a subpage? Here's what we have now: https://docs.inedo.com/docs/proget/installation/installation-guide/linux-docker In any case, we are definitely open to collaborating with ways to improve not only our API, but our docs. Seems this might be a great way to work together? We honestly don't anything but basic knowledge on swarm / Stack Files, so if you could write how you set it up / monitor it, we will be happy to fix the code to work with the docs. I suspect changing the API to work as you requested would be infinitely easier for us than figuring out Docker swarm :) Also --- please note that we are now using proget.inedo.com instead DockerHub, it seems a lot of other vendors are doing the same, and it's easier for us to maintain our own build process (not possible on Dockerhub).

Hi @scroak_6473, That's great to hear that the impersonation has fixed the issue. We have fixed this issue to not require impersonation in ProGet 5.3.2. I will let you know if anything changes! Thanks, Rich

Hi @scroak_6473 , Yes, I have included this fix in 5.3 as well. It will be released as part of ProGet 5.3.1. Thanks, Rich

This is the sort of error you can expect when the application code and database are not the same version. Had you installed the the same version you had on the old server, it wouldn't be a problem. But fortunately it's an easy fix I think. Just follow the Database Manual Installation Instructions and run inedosql against your database. Then it'll get updated to the right version. FYI please review the Backing Up & Restoring as well :)

Whoops, I accidentally forked the topic, so I'm just going to quote it in here instead @smolkov-anton_1636 said in Unlisted NuGet Packages showing as listed in feed: @atripp Hello. I have got the same behaviour too. With fiddler i see that all versions i unlisted before have property <d:Listed m:type="Edm.Boolean">false</d:Listed> , but still apeear in VisualStudio, nuget list and even Rider. Version - 5.3.0 (Build 126-5.3.0). I think this one is related: https://forums.inedo.com/topic/2675/owner-has-unlisted-the-package-on-nuget-org-but-proget-still-shows-it-in-the-list-of-availible-versions/4 @smolkov-anton_1636 said in Unlisted NuGet Packages showing as listed in feed: @atripp Hello. I have got the same behaviour too. With fiddler i see that all versions i unlisted before have property <d:Listed m:type="Edm.Boolean">false</d:Listed> , but still apeear in VisualStudio, nuget list and even Rider. Version - 5.3.0 (Build 126-5.3.0). I think this one is related: https://forums.inedo.com/topic/2675/owner-has-unlisted-the-package-on-nuget-org-but-proget-still-shows-it-in-the-list-of-availible-versions/4 @smolkov-anton_1636 said in Unlisted NuGet Packages showing as listed in feed: The same is for new nuget V3 API. Steps to reproduce: Unlist all versions of package in proget UI List only one version / push new version Expected result: Visual Studio UI shows only one version which was listed Observed result: Visual Studio UI shows all the versions

Not in particular; .NET does garbage collection, in the background, as needed; so it's not uncommon to see processes "swell" to consume available memory and then "contract" overtime, as memory usage (percentage-wise) gets high.

Ok. Thanks. I will hunt it down.

@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.

Thanks for the update.

Hello; That's a good question; we can't reproduce this, if the file is instantaneous through the browser, we can be totally assured that the problem isn't ProGet finding and sending that .deb file over the web. apt install isn't any more complicated than that. Can you put a sort of Proxy Server or traffic monitor between the two? Maybe it's network related? Maybe at a TCP/SSL packet level? Maybe apt has a sort of throttle? I guess you could also try to curl the file from whatever server you're doing apt install on to further track it down? hope thsi helps track it down, please share what you find in case anyone else experiences it. Alana

In my opinion, using $ApplicationName is not possible, at least for Gitlab Indeed from GitLab ref, we read : The URL a badge points to, as well as the image URL, can contain placeholders which will be evaluated when displaying the badge. The following placeholders are available: * %{project_path}: Path of a project including the parent groups * %{project_id}: Database ID associated with a project * %{default_branch}: Default branch name configured for a project’s repository * %{commit_sha}: ID of the most recent commit to the default branch of a project’s repository As %{project_path} is different from $ApplicationName if the project is defined in a group, the only link between the gitlab project and the builmaster application is the commit_sha var. I think you just need to add stage as querystring and make the search for the result of the pipeline named stage for which exists an active build variable ($commitId in my example) with a value of commit_sha. and $commitId has to be unique over all BuidMaster. Actually, it is not possible to get more variables (ideally %{project_path} at the GitLab::Get-source step. The filter would be then better (Filter for project_path+ commitid + stage), but this is still a build variable and not an implicit variable like $ApplicationName I don't know if there a better way because I have just started to use Gitlab.

Hello; it's the first request for this, but we're going to investigate adding this to ProGet as PG-1702. We'll update as we make progress on investigation.

Hmm, for this, then it seems -Repository is the argument?

For this case, you're right -- the Instance ID would be the way to go. On the new BuildMaster server, you can set the Agent.InstanceId field (any string is fine, "bm62" would work) , so this way, both BuildMaster instances won't collide. We are using our "Customer Success Program" to provide upgrade assistance for BuildMaster 6.2, so the best way to get started on this would be to talk to your account representative. You can also submit a ticket and put 6.2 UPGRADE in the "How can we help" section, and we'll route that to the right people :)

I noticed that the latest Proget version has a v3 connector for nuget so I added that and also re-indexed the package store, recomputed the checksums and deleted invalid packages. While running the re-indexing I encountered three errors that indicated bad packages (files in use), so I deleted all three packages, ran the re-indexing and everything appears to be working again. I suspect the problem was the bad packages in the store. Thank you @atripp for your help in this matter.