Hi @tcochran_0018,

This looks to be related to a known bug, PG-2193, that is expected to be released this week in version 2022.7. These errors shouldn't affect the operation of anything, but please let us know if it does.

Thanks,
Dan

Hi @kichikawa_2913,

Good catch! It looks like this is missing from our documentation. I'll work to get it updated this week!

Thanks,
Dan

Hi @kichikawa_2913,

Thank you for following up with us and letting us know it is working now. Also, thanks for clarifying the Docker network setup for me. This is related to how we changed the service messenger in ProGet v6.

I took a deeper look into the code and when setting the endpoint via the "change" link, it will override the configuration's shared value. Once that has been set, it will use the configuration associated with that node instead.

Based on your screenshot, it looks like it was using tcp://*:6001 as the shared configuration (even though you said not to), but failed to connect because it was trying to balance amongst the other nodes. If you were using a Docker network, this most likely would have worked because the individual nodes could have listened on 6001 as well.

After reviewing these changes, you would have to change the service messenger address on each service node in order to apply the configuration you are looking to use (which is what you did above).

Hopefully this gave a bit more context to this change.

Thanks,
Dan

Hi @kichikawa_2913,

Thanks for following up and letting us know that you found the solution!

Thanks,
Dan

Hi @claudio_9251,

I'm not too surprised by this. NuGet has deprecated many of it's ODATA( v2) endpoints which has caused some issue within ProGet, we have documented this in our NuGet v2 troubleshooting guide. It is very possible that Telerik (Progress) has not made these changes on their end which may be causing this. This is especially true when it comes to connectors because ProGet will pass through a lot of the V2 queries the client makes to the remote endpoint. Either way, the NuGet v3 API is the proper API to use going forward and we highly suggest using that.

Thanks,
Dan

Hi @dm-sidelnikov_5266,

I see the email, thanks for sending this over! Please give me some time to review and I'll let you know what I find.

@pieter-mertens_0372, your issue may be related. Although both products are owned by Microsoft, they still differ in their implementation. Does this happen for all packages or just a specific subset?

Thanks,
Dan

Hi @arozanski_1087,

We talked it over in our team meeting yesterday and decided to change ProGet to always create a new release when one doesn't exist and add new dependencies when the release does exist. This way that parameter will not be needed. So you will just need to upgrade ProGet to v2022.23 when it is released later today.

As for the Yarn support and scanning multiple package types in the initial scan, we plan to work on that early next week, so we should have something for you soon.

Thanks,
Dan

Hi @itops_6398,

I'm very happy to hear that you got this working. You typically do not need the UPN because it will be automatically appended when searching for the user in your domain, but it doesn't hurt to be there. There are typically only two scenarios when the UPN is needed; when that username is already in the built-in directory or you have a multi-domain forest setup in Active Directory, then the UPN will tell it specifically where to look.

With all that said, if it is working for you now, then I would leave it as is because SAML and AD/LDAP are difficult enough as it is. We are going to add the transform information to our SAML docs in hopes of helping others later.

Thanks,
Dan

Hi @forbzie22_0253,

You can do this using our Bulk Import via a drop path feature. We have a helpful How To Bulk Import Packages Into A Feed From Disk article in our documentation.

Please let us know if you have any other questions!

Thanks,
Dan

Hi @lucas-almeida_8120,

This a known issue that we are currently working through. It seems to be an issue with some bad/duplicate data in your database. The current workaround is to downgrade to ProGet 2023. We are hoping to have a fix ready soon.

Thanks,
Dan

Hi @caterina,

We're a bit concerned that this is too specific for your usecase, and we're really struggling documenting it.

Instead of doing this, we're thinking it might just make more sense to run (Get-Item 'C:\path\to\file.exe').VersionInfo using PowerShell and export these into variables instead.

For Example:

$versionInfo = (Get-Item 'C:\path\to\file.exe').VersionInfo
$version = if($versionInfo.FileVersion) { $versionInfo.FileVersion} else { $versionInfo.ProductVersion }
$productName = $versionInfo.ProductName
pgutil builds scan --input=myApplication.csproj --project-name$productName" --version=$version

Thanks,
Dan

Hi Mike,

The Asset API does require the DownloadPackage permission. Currently, only the ProGet UI can be used with the ViewFeed only permission. I'll add this as a note to discuss in the next products meeting early next week.

Thanks,
Dan

Hi @sgardj_2482,

You can create a custom task under Administration -> Manage Security -> Tasks / Permissions then click Customize Tasks in the upper right corner. When you do that, you can create custom task that has the View Feed permission. That will allow a user to view an asset's metadata in the ProGet UI and not be able to download the package.

Thanks,
Dan

Hi @caterina,

This looks to be an issue with pgutil. I just pushed an update to pgutil, 2.0.3, that includes the fix. If you update to that version, you should be able to promote builds now.

Thanks,
Dan

Hi @forbzie22_0253,

The easiest solution is to change both the "ProGet Service" (INEDOPROGETSVC) service and the "World Wide Web Publishing Service" (W3svc) to Automatic (Delayed Start). This typically allows SQL Server to start before IIS and the ProGet Service start.

Thanks,
Dan

Hi @parthu-reddy,

This is usually an indication of an outside process accessing this file. To verify this, if you restart ProGet, access to that file will be restored. If it is still locked, then something external to ProGet is accessing it. The most likely culprit is an antivirus scanning that file when ProGet attempts to access it.

Can you restart ProGet and see if there is still a file-locking issue? If the file is still locked, can you verify that you do not have an antivirus solution that is constantly scanning that file and locking it?

Thanks,
Dan

Hi @sonali-prasad17_0018,

Are you able to see the packages from the mirror in your Debian feed within ProGet? Also, do you get any errors when trying to update your source in Ubuntu?

Thanks,
Dan

Hi @maciej-luszczynski_5271,

Thanks for bringing this to our attention. I have corrected the example as suggested.

Thanks,
Dan

Hi @parthu-reddy,

Can you tell me what version of ProGet you are using? It looks like this issue was fixed recently, PG-2688, in ProGet 2024.5. I believe if you upgrade to 2024.5, that should fix your issue.

Thanks,
Dan

Hi @forbzie22_0253,

ProGet will connect to https://my.inedo.com/services/v1/activate for activation.

Thanks,
Dan