@rhessinger Hey Rich,
No worry I followed up closely and I knew the release including the fix was coming!
I updated ProGet yesterday morning, updated my connector and our NPM feed page is back alive. Off course the connector can't tell me how much packages there's upstream but that's no big deal.
I asked our team using this NPM feed connector to let me know if they encounter any issue.
Thanks again for the amazing support it's highly appreciated.
@rhessinger said in Connector to Azure DevOps NPM package feed not working:
http://PROGET_SERVER/feeds/NPM_FEED_NAME/PACKAGE_NAME/versions
Hey Rich,
I just figured out that if I add this broken connector to this DevOps NPM feeds in my ProGet NPM feed it will break the ProGet NPM packages page.
As we know with this issue the connector isn't working and it gives us this error:
I did not expect that having this broken connector setup would crash my whole NPM feed page:
We would be fine if the connector would be skipped regarding listing the packages on the feed webpage but would still let us download the package directly with the NPM command as you mentioned (I tried it and was able to reach specific version pages on ProGet)
If it can make your life easier by just fixing the NPM page we would be fine with it.
Hey @rhessinger,
Thanks a lot for the feedback it's really appreciated. Hopefully I won't be on your blacklist since I'm always coming in with Microsoft issues haha.
I'll stay tuned for the solution.
Best Regards,
Nicolas
@dean-houston Hey Dean,
Thanks a lot!
Yes we do have a license and use it to full potential. Microsoft is giving us/you a hard time with their DevOps feed.
Will stay tuned for the update and let me know if you need anymore information.
@stevedennis
I created a dummy collection with a dummy project and a dummy feed on Azure DevOps that contains 1 NPM package.
I sent the information (feed address and PAT) in an email with "[QA-529] issue with ADO NPM feed connector" as subject.
Thanks,
Nicolas
@stevedennis Hey Steve,
We tried that without success as well:
Microsoft is giving us a hard time to make it work with your product as usual.
If you have any idea or have anyone that's familiar with creating connector to an Azure DevOps feed I would be more than grateful!
We are trying to connect our ProGet instance to a DevOps NPM Artifacts feed.
We are unable to connect to it using ProGet connector, but the token used is valid and has access to the Azure DevOps feed.
Step used to create the connector:
Login to the Azure DevOps Project and generate a token with the needed rights (Packaging Read, write, manage)
Go on the Azure DevOps project needed feed and give Read access to the user for which we created the token
Login to ProGet and create a new Connector
Feed type : NPM
Connector URL : Azure DevOps feed URL
Connector name: The name we want
User name: token (also tried genetecux which is the name of the project)
Password: AzureDevops Generated token value (tried encoded in BASE64 as well)
Authentication: default (tried basic and bearer)
Timeout (seconds):10
Associated feed:npm
Run the service Connector Health Check
Get the error :
Do you have any idea why we can't make it work and if it's a known issue?
Hey @apxltd ,
Yeah having to deal with Microsoft on many different issues ourselves I totally get what you mean with this picture. I also totally understand your point and that makes sense! I'm glad the NuGet teams also push for the changes when they can.
For us since everything is standardized and automated using the NuGet Restore task in our DevOps build pipelines yes it's really more convenient for us to point to our Proget Feed (thanks again for your product) and gather everything from there. We can for sure find workarounds also on our side but we had to try and contact your team as your company has been way more helpful to us than any support from Microsoft.
Thanks a lot for yours and Rich`s precious time spent helping us through this issue.
Hey @apxltd,
I didn't expect it to reach all the way to you but it is a honor that you take care of the issues.
Here is our use case:
Most of the dev teams in our organization use DevOps on premise and push the NuGet to our Proget NuGet feed directly since we manage most build definitions.
Some of them need or want the new features that are available on the cloud version of DevOps so they move all their work or part of it online and my team doesn't manage what they do in their online collection. This is why some packages are hosted on their cloud DevOps feed. It's no problem until other teams need to use their packages and that's what happened here with this very specific case of an empty dependencies section.
To begin with I totally agree with you that the ADO Packages team are really not playing nice and fair by not being compliant with spec to make sure we only use their products. As you might saw with the previous comments I tried to speak to Microsoft about that too and they basically told me to deal with it as they won't change anything...
I'm now surprised to get the same kind of answer coming from your company. We are probably not the only customer using DevOps in the cloud and running into these issues but I might be wrong. Off course as you said I could do like some others did. I could try to contact all the devs and try to configure their DevOps pipelines so they push directly to our private Proget NuGet feed but since it's an independent online platform outside our infrastructure it's easier said than done as we are a 1000+ employees company.
I will see what would be possible to do on our side as well with your recommendations. I understand what you say and that it would request a constant effort from your team to keep this use case alive and working every time Microsoft updates their platform but if that's not a heavy load on your side I think it would be a good investment since Microsoft is a major player and they keep pushing people to go on the cloud version. On a more positive note we do enjoy Proget a lot and I am glad to get feedback from your team.
Hey Rich,
No problem it's my fault for omitting this detail. I assumed that ProGet was just not compatible with V3 because of the error message we were getting.
I sent the Json for this particular DevOps via email (subject : Nuspec file with an empty group in dependencies breaks Proget)
Thanks again for the fast feedback
Hey Rich,
Just to clarify something. My connector to Azure DevOps uses the V2 version as the V3 would simply not work.
This is the current configuration:
I created another one with the same token using the V3 Url. Here's the result in the Administration overview when I do a connector health check:
Hey Rich,
I can see the package and the versions available in the ProGet UI:
The ones that have never been installed manually (with the antenna icon) from the UI using the download button in the UI will not work trying to download it with the NuGet install command.
The one that already been downloaded (so cached) will work just fine with the NuGet install command.
Since the feed is used mainly by TFS for the build pipeline we can't rely on people doing download the new NuGet manually every time.
Is there something I did wrong setuping the connector?
Thanks again for the incredible support!
Hey Rich,
We have some errors (404 not found..) but nothing related to that. I tried to pull the NuGet wtih the nuget install and nothing showed up in the Diagnostic Center log messages.
I didn't kill and recreate the connector to teh DevOps feed. Do I need to do that? I only deleted the NuGet and all its versions from our feed to force the cache.
Hey Rich,
My bad I posted it on the wrong feed.
We still have the issue after updating to 5.3.18 this morning:
Do you know if that should have been fixed? According to the change log it should been fixed:
PG-1851 - FIX: NuGet v3 dependencies with empty ID will throw null exception
Hey Rich,
No need to apologize I appreciate your quick feedback and action.
We will make sure to update when this version comes out!
Thanks again,
Nicolas Morissette
Hey Rich,
Thanks a lot for your support.
I contacted Microsoft as suggested but they sent me back to your team as predicted.
Here is their answer :
Hey Rich,
It works when I download it manually from the Azure DevOps feed and upload it manually in our ProGet NuGet feed. Then I can install the package without any issue.
Hey Rich,
Here's an example directly from the feed (I used a viewer but you can see the values). It doesn't look like it has empty values
Hey there here's our use case:
An error occurred while retrieving package metadata for '**PackageName_Version**' from source '**our Proget Feed url**'.
id
catalogEntry: {
authors: "***",
dependencyGroups: [
{
targetFramework: "netstandard2.0",
dependencies: [
{
id: "",
range: ""
}
]
}
],
description: "Package Description",
id: "**PackageName**",
published: "**Date**",
version: "**Date**"
},
The problematic part appear to be the empty id & range in the dependencies array, which should not the be there.
We looked at the NuSpec specifications and it seems normal to have a dependency group event if there`s none.
Let us know if it's really a ProGet bug or any more information regarding this error. Thanks a lot!!
Hey @rhessinger
Thanks a lot for the incredibly fast answer.
I will try to find a solution on our side with DevOps then.
Have a nice day,
Nicolas
Hey there,
I'm getting the following error when trying to access one of our https://pkgs.dev.azure.com instance feed:
System.Net.WebException: The remote server returned an error: (401) Unauthorized.
at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)
I get this error when I create the connector using my username (Username@__domain__.com) and matching password.
If I create a personal access token (PAT) for this user on the Azure Devops cloud Instance then create a the connector using token username and the token value as password it works just fine.
Are Username and Password not suppported for Azure DevOps cloud feed?
It's annoying because our PAT are valid for only 1 year and it adds some PAT managing we would like to avoid.
Thanks,
Nicolas