Frustrating experience contributing to a integration

[NinoFloris]

Consider the flow for a new contributor (me) that's trying to improve a component they're interested in.

After cloning I began by opening the component project I was interested in, made my changes, everything good so far. Once I was done with the implementation I naturally wanted to run the tests locally. I couldn't directly load the test project given it has its own dependencies and they didn't want to restore (maybe they need to be loaded as well, maybe this is a Rider shortcoming, I'm not sure).

So time to open the main sln with 200+ projects. At this point frustration sets in as you'll be forced to get a coffee while Aspire downloads the internet. It's very likely people with less powerful hardware would not just wait forever for the restore but also have very long delays to load and build all these projects. Afterwards there were still errors in Rider that required manual intervention (mostly playground project issues). OK, time to run the tests I originally set out to do. I was immediately confronted by what looked like hanging tests. I traced the issue to the fixture containers coming from a registry that only seems to be fast in the US(?) (netaspireci.azurecr.io) so these tests seemed to hang while the required container(s) crept in at kb download speeds, zero feedback. So instead I copied the full image name from the debugger and got another coffee while it was pulled in via the docker cli with some progress feedback. Finally I could go back to the IDE and get the the tests to run successfully. Overall this was not a smooth experience considering how young this repo is.

I'm reporting this because I care; in the end a small contribution that could have been a < 30 minute fun adventure took me 2 hours. (and it goes without saying that not everybody will even make it to the end). That's a shame, as it's mostly down to some organizational papercuts that affect newcomers most.

Would it be an idea to split the projects with their tests out into their own folders (with their own solution file) like in dotnet/runtime? This would allow narrow contributions to be done more easily.

When it comes to the registry issue, if it can't be fixed so it's fast worldwide some steps must be taken to alleviate the situation:

• Mention this in contributing.md (and any other issues like these)
• Maybe some form of download progress can be reported via testcontainers? (would that be a valuable feature for them to add to the roadmap?)

[eerhardt]

Thanks for your feedback here, @NinoFloris.

So time to open the main sln with 200+ projects. At this point frustration sets in as you'll be forced to get a coffee while Aspire downloads the internet. It's very likely people with less powerful hardware would not just wait forever for the restore but also have very long delays to load and build all these projects.

FYI - @davidfowl @mitchdenny. I agree that we have too many projects in our solution. It is degrading the developer experience.

I was immediately confronted by what looked like hanging tests. I traced the issue to the fixture containers coming from a registry that only seems to be fast in the US(?) (netaspireci.azurecr.io) so these tests seemed to hang while the required container(s) crept in at kb download speeds, zero feedback.

Let me see if we can geo-replicate this Azure Container Registry, so it can be faster outside of the US.

See also Change the source layout for integrations (dotnet/aspire#6517), which may help when only contributing to a single (or small number of) integrations.

[eerhardt]

Let me see if we can geo-replicate this Azure Container Registry, so it can be faster outside of the US.

I've added a European and Asian replica to the container registry. Hopefully that solves this problem going forward.

[NinoFloris]

Thanks @eerhardt I can confirm the download speeds are much better now.

[davidfowl]

I think we may need to do the split into multiple solutions to make this more usable. We would still have the uber solution though.

[IEvangelist]

Please consider using *.slnx for more localized solutions. Perhaps scoped to:

• src project with minimal other project references
• playground project if available
• tests project