Nuspec file with an empty group in dependencies breaks Proget

[apxltd]

Hi @nicolas-morissette_6285 ,

Can you help me understand the use case here of ProGet and Azure DevOps Packages? Basically I'm a bit hesitant to invest in continued work-arounds for bugs/quirks in ADO Packages.

The ADO Packages team has made it very clear they aren't interested in spec compliance (whether NuGet or otherwise), and that they won't support interoperability with any other tool aside from Azure DevOps. That makes sense because they want you to only and entirely use Azure DevOps.

We've already work around one quirk, and I have little confidence that fixing this quirk will actually solve the problem (i.e. enable the use case you're trying to build) and that it will stay fixed. In a few weeks/months, when they ship some new functionality, your hybrid-ADO Packages usecase may break again.

For example, when ADO-Packages decided to block "private upstream feeds" (I guess that's what it's called?), it disabled the use-case of having ADO-Packages pull from ProGet servers, or vendor's feeds, or anywhere other than NuGet.org or ADO-Packages feeds. Fortunately it's easy enough to work-around in ADO.

Bottom line, using ADO Packages this way may prove to be very fragile, and you may be better served by not using ADO Packages altogether. A lot of other users have made that decision, and ADO works fine (better IMO) without using their Packages feature... and it's highly likely it will continue to indefinitely.

Alex

[nicolas.morissette_6285]

This post is deleted!

[nicolas.morissette_6285]

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.

[apxltd]

Hey @nicolas-morissette_6285,

Thanks for clarifying!

So it sounds like this is a non-critical integration point. In other words, you're not building a workflow that relies on the two to be integrally connected, it's more a "convenience" such that one team get another team's developer library packages more easily.

I'm more nervous about enabling / encouraging the first use case; given the velocity and unpredictability of ADO's changes, there's a high change it will "just break" some day -- and as you've seen from their support, it's hard to get "them" to care. We most definitely care, which is why I'm cautious about putting us in a position to be responsible for customers' infrastructure breaking on account of a third-party API suddenly changing.

We most definitely work with a lot of teams at Microsoft, but their internal org hasn't really changed in the many years since I first saw this...

... so a lot of times, it's partnering with customers to push different groups at Microsoft to work together to serve what should be their common interest (i.e. a paying customer). For example, getting AzureDevOps Packages and NuGet team to collaborate on API things.

After the change in guard at VSO/ADO(i.e. after Ed Blankenship), we really don't have any meaningful contacts or pull w/ that group. But we definitely have contacts and work closely with other teams (like NuGet team, etc).

All that said, we'll also work-around this quirk, and I've put in a change (PG-1862) to accommodate this. But just

[nicolas.morissette_6285]

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.