dotnet / aspire

An opinionated, cloud ready stack for building observable, production ready, distributed applications in .NET
https://learn.microsoft.com/dotnet/aspire
MIT License
3.47k stars 370 forks source link

API projects named the same causes issues with AppHost #2770

Open oridotaoyebode opened 4 months ago

oridotaoyebode commented 4 months ago

Hi Guys.

I hope I articulate myself well enough to make this issue easy to understand.

Given the following project structure where multiple of this exist in a solution

Screenshot 2024-03-11 at 07 55 37

When adding the API project as a reference to Aspire.Host project type, Aspire is unable to differentiate between the projects based on folder structure.

For example : The following is autogenerated for the API project.


namespace Projects;

[global::System.Diagnostics.DebuggerDisplay("Type = {GetType().Name,nq}, ProjectPath = {ProjectPath}")]
public class Api : global::Aspire.Hosting.IProjectMetadata
{
  public string ProjectPath => """/Users/xxxxxx/Documents/GitHub/xxxxx/Example/src/Api/Api.csproj""";
}

Assuming I had another Solution folder named "Identity" with a similar project structure, as above and another API project named API, the following will be generated.


namespace Projects;

[global::System.Diagnostics.DebuggerDisplay("Type = {GetType().Name,nq}, ProjectPath = {ProjectPath}")]
public class Api : global::Aspire.Hosting.IProjectMetadata
{
  public string ProjectPath => """/Users/xxxxxx/Documents/GitHub/xxxxx/Identity/src/Api/Api.csproj""";
}

When adding the project the project reference in the program.cs file inside the AppHost project, youw would normally do something like this

var example = builder.AddProject<Projects.Api>("example-service");

However, because API project is named API in example and the same in Identity, the Projects namespaces doesn't see them as two different project thus, you are only able to add one.

DamianEdwards commented 4 months ago

Folks can workaround this by using the AspireProjectMetadataTypeName attribute like <ProjectReference Include="../Example/src/Api/Api.csproj" AspireProjectMetadataTypeName="Example_Api" />.

But I'm interested in what the thoughts are on how we could fix this automatically? A more complicated logic in our MSBuild targets that detects the conflict and auto-differentiates somehow? Even then, what would it do to differentiate? Add an index (eww)? Use the parent directory name? I'm not sure there's a good default way for us to resolve this that's robust.

@eerhardt?

eerhardt commented 4 months ago

IMO adding an index isn't an option. How would the dev know which one is which?

Using the full parent directory and finding the first differentiator might be an option. Note it can't just be the first directory up. In the top comment, both projects are under src/Api/Api.csproj. So we'd need to keep walking up until we found Example vs Identity.

oridotaoyebode commented 4 months ago

Honestly. I think maybe a way to manually specify the projects paths as an option ?

Secondly, this might be a bad idea because I don't really understand how it generates the files. ... but I am guessing one of the reason the Aspire hos project is seeing all of the API project as one API is because the autogenerated files all use the same namespace?

If we generated the files with the namespace of the actually project it's sitting in? Would that allow us to specify reuse the same API project name multiple times ?

@DamianEdwards @davidfowl @eerhardt ?

davidfowl commented 4 months ago

Honestly. I think maybe a way to manually specify the projects paths as an option ?

Already exists

oridotaoyebode commented 4 months ago

Thank you @davidfowl this might be a better option for project structures like this