Hi @jn_7742,

This fix will be released in ProGet 5.3.21 which is due out January 22, 2021. When you upgrade and test this, can you please reply back and let us know if this worked for you?

Thanks,
Rich

Hi @viceice,

I took a look at this and it looks like the issue is that the GitHub repository is not returning the published date. I have put a fix in, PG-1871, which will release in ProGet 5.3.21.

Thanks,
Rich

Hi @viceice,

This typically happens because the NuGet package metadata has an invalid format. Does this error happen for all packages or just one?

We run into similar issues when connecting to Azure DevOps registries because they do not always follow NuGet's API spec. Are you able to send over the package registration metadata for a package with the issue? The index.json may also help with this. If you do not feel comfortable submitting this via the forums, you can email it to support@inedo.com. Just please let me know when you send it so I know to look in that mailbox for it.

Thanks,
Rich

Hi @Crimrose,

Thanks for posting a follow-up solution for this! I'll keep this in our notes incase this comes up again in the future!

Thanks,
Rich

Hi @nicolas-morissette_6285,

Thanks for sending that over. This confirmed my thoughts. It looks like they only include the SearchQueryService/3.0.0-beta, not the SearchQueryService, which is why the v3 connector does not work. I'm going to talk this over with the internal team and see how we want to approach it. ProGet currently does not implement the 3.0.0-beta API endpoint because it is still likely to change, which increases the likelihood of it breaking in ProGet.

I'll discuss this internally and figure out the best way to proceed.

Thanks for sending this over!

Thanks,
Rich

Hi @nicolas-morissette_6285,

Would you be able to post the JSON from your v3 API? It looks like AzureDevOps is missing the URL for the SearchQueryService. If you navigate to https://proget.inedo.com/nuget/NuGetLibraries/v3/index.json You'll see the very first service API URL is for SearchQueryService. I'm wondering if Azure DevOps is implementing a weird version of it, if at all. If you don't feel comfortable posting it here, you can email it to support@inedo.com, let me know, and I can pull it from there.

I'm sorry for the confusion. Since you originally posted the values from the registrations-gz, I made the assumption you were using the v3 API. The fix I added was for the V3 API JSON. I'll have to see what I can do with the V2 version because it parsed a little differently than the v3 version.

Thanks,
Rich

Hi @nicolas-morissette_6285,

Thanks for the updated information. This is most likely not a configuration issue with the connector. The only thing that could be affected by the connector setup is if you are using a v2 API NuGet feed instead of a v3 on from Azure DevOps, but I believe you already confirmed above that it was the v3 API from Azure DevOps.

Let me look into this a bit further. It looks that I must have changed the code that the UI uses, but not what the nuget.exe uses. I'm not sure how that is possible, but let me take another look.

Thanks,
Rich

Hi Simon,

Unfortunately hitting the URL in the browser will not show the underlying error because the Docker client is a relatively chatty client. It will hit a number of different API endpoints to perform the login. You would need to use a tool like Wireshark or Fiddler to proxy requests to the server to see which URL has the problem.

Are you using nginx as a reverse-proxy to ProGet? Is it possible to bypass it to try to use docker login directly on the ProGet server to rule out any header manipulation issues?

Thanks,
Rich

Hi @nicolas-morissette_6285,

You should not need to do anything to the connector. Can you try and open the package in the ProGet UI? Does that package/version load? Also, can you download it within the ProGet UI?

Thanks,
Rich

Hi @scroak_6473,

We have fixed the issue with creating new AD User Directories and vulnerability sources in .NET 5. It is set to release in ProGet 5.3.19 which is due out December 18, 2020.

Thanks,
Rich

Hi @nicolas-morissette_6285,

No problem. Thanks for moving the comment over here! I will delete it from the other topic.

I can confirm the fix I made was released and is currently in the code. Do you see any errors in the Diagnostic Center in ProGet?

Thanks,
Rich

Hi @scroak_6473,

For the add new User Directory and add new Vulnerability source, we have identified the issue and we are currently investigating the cause of it. It has to do with changes in .NET 5 for parsing types from strings. I will update this when we have a bit more information on it.

As for the AD stuff. That is definitely the issue, the LDAPS certificate is not being viewed as a valid certificate. I think we will need to investigate this further on how to bypass certificate validation. I would prefer you to open a new thread to discuss this issue with LDAPS in Docker. To answer your question, our code for connecting to Active Directory exists on GitHub in the inedox-InedoCore extension. It also includes a windows application for testing AD connections, including LDAPS. The library we are using on .NET 5 is Novell.Directory.Ldap.NETStandard. For the .NET 4.5.2 target, we use the typical System.DirectoryServices. We always encourage Pull Requests with fixes for this also!

Hope this helps!

Thanks,
Rich

Glad to hear the workaround works. We are still currently working on the issue to fix the Add New functionality in .NET 5. To the best of my knowledge, LDAPS is currently working and we have users that are using it currently. Can you please tell me what issue you are having with LDAPS?

Thanks,
Rich

Hi @scroak_6473,

I was able to recreate your issue. I think this may be an issue with the .NET 5 version of ProGet and creating a new Active Directory (LDAP) user directory. If one is already created, I do not have any issues editing it.

As a workaround, I would suggest changing over to the progetmono image and create the new user directory, then change back to the proget image to configure it.

I will reply back when I have an update on a proper fix for this.

Thanks,
Rich

Hi @shijiyong_6709,

I just wanted to confirm that you are using docker login -u admin https://proget.company.com and not docker login -u admin. Is that correct?

The first thing we need to figure out is if the problem exists in your ProGet configuration or in your nginx configuration. Can you start with temporarily allowing anonymous access to your Docker registry in ProGet, does Docker pull work then?

Thanks,
Rich

Hi @arozanski_1087,

That's great! I'm sorry it took this long to get this working. Thanks for working with me to figure this out! I'm going to make a change to the documentation right now to include the requirement of naming the extension file. I will also get a full release of this extension out today so it will lock in that version with the ProGet release tomorrow.

Thanks,
Rich

Hi @arozanski_1087,

Glad a reboot of the OS fixed it. Can you try renaming the downloaded version to InedoCore.upack. I noticed ProGet gave me some issues installing the extension manually when leaving the version number on there.

Thanks,
Rich

Hi @arozanski_1087,

You can also try flipping back to the Built-in User Directory by reseting the base admin account. You won't lose any AD users you have setup, it just simply switches ProGet to use the Built-in directory and resets the Admin password back to Admin.

Thanks,
Rich

Hi @arozanski_1087,

Did you restart IIS or the Integrated Web Server after copying the upack file back? Also, did your upack file have a version number in the name? Or was it just InedoCore.upack? I doubt this, but can you navigate directly to /administration/extensions? Could you also take a screen shot of the files in the Extensions folder?

Thanks,
Rich