Add tags to hosting packages for easier searching

[kiapanahi]

Related to #1314

This PR moves all Aspire.Hosting.* project to /src/Hosting/ and adds a directory-specific Directory.Build.props to said directory to manage common and specific hosting-related tags.

It also adds relative <PackageTags>...<PackageTags/> to all Aspire.Hosting.* projects.

Microsoft Reviewers: Open in CodeFlow

[davidfowl]

This PR moves all Aspire.Hosting.* project to /src/Hosting/ and adds a directory-specific Directory.Build.props to said directory to manage common and specific hosting-related tags.

This sort of huge move isn't great without coordination with everyone working on the project. This isn't something we would take as it is a very disruptive change that affects all existing changes anyone is making.

Can you make a smaller change that doesn't require moving all of the existing source code around?

[kiapanahi]

Can you make a smaller change that doesn't require moving all of the existing source code around?

This would require "manually" adding project tags to all hosting-related projects due to the missing localized Directory.Build.props.

The downside would be "some" manual overseeing and orchestration. On the upside, the changes would be dramatically less.
Would that be acceptable to the team?

[davidfowl]

The downside would be "some" manual overseeing and orchestration. On the upside, the changes would be dramatically less.
Would that be acceptable to the team?

Yes

[kiapanahi]

Done :)

[davidfowl]

5 files instead of 209 😄

[sebastienros]

@kiapanahi you should rebased your branch on main, the current diff includes too many other unrelated changes.

[kiapanahi]

@kiapanahi you should rebased your branch on main, the current diff includes too many other unrelated changes.

Had done that on my other machine but somehow it was not pushed (or I forgot to update my forked main branch beforehand maybe).

Just updated the branch again; now it only includes the 5 related changes

[sebastienros]

Much better, thanks.

Now that I see the changes, I wonder how it actually makes the search better? The tags are only the list of word that the package names are made of, for instance aspire hosting azure provisioning for Aspire.Hosting.Azure.Provisioning. At that point I wondered if NuGet was not already clever enough to tokenize the package names using the dot, so I did some searches with Aspire, or Aspire Azure, Aspire Dapr, and got exactly the packages you would expect. And these are the exact keywords you are suggesting in this PR. At that point I am not sure how it makes the search easier.

I tried on nuget.org, maybe Visual Studio uses a different API for the search.

[kiapanahi]

I tried on nuget.org, maybe Visual Studio uses a different API for the search.

Fine point. I don't see why the APIs should follow a different search path than the web application front end. I haven't tested myself either.

The main reason for this PR was to address @timheuer's concert for consistency rather than search optimization (link to the issue). I admit the titles (both the issue and this PR) could be seen as a tad misleading though. If the consistency of package names is not a relatively valid concern in the hosting part of Aspire packages then this work would probably loose its main purpose.

Back to your point on NuGet being clever enough, I naively didn't do the search myself and just assumed that it wasn't that clever.

[sebastienros]

One advantage I see with tags is that you can create formal groups, instead of relying on word similarity matches.

I had not paid attention to the issue you are referencing, sorry.