Aspire Starter Template Fails to Create Solution File

[khalidabuhakmeh]

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the bug

When not using the .NET CLI, using the Aspire Starter Template produces all the projects but no solution file to tie them all together. This occurs in tools such as JetBrains Rider.

I've traced the issue to this exclusion in the template.json file.

https://github.com/dotnet/aspire/blob/9d504bf4ed75cb007dabee259dbd6e666ee861fe/src/Aspire.ProjectTemplates/templates/aspire-starter/.template.config/template.json#L38-L55

Expected Behavior

The projects and solution file linking them is created.

Steps To Reproduce

1. Start JetBrains Rider
2. Create a new Aspire Solution using the Starter template

Exceptions (if any)

No response

.NET Version info

I've tested this with workloads in the .NET 8.0 and .NET 9.0 preview bands.

Anything else?

No response

[radical]

cc @DamianEdwards

[DamianEdwards]

This was an intentional change based on similar configuration in the Blazor project template (it's a little indirect there but the effect should be the same).

My understanding is that it's expected that non-CLI environments should be auto-creating a solution file when creating new projects (this is what Visual Studio and the C# Dev Kit do).

/Cc @sayedihashimi @phenning

[ArtManyak]

@DamianEdwards to be honest, it's kinda confusing that the "solution" template doesn't generate the Solution file in some specific cases. This is not a problem at all to create the new Solution file in such cases. But for me it indicates a broken template. By default, Rider creates the Solution file by themself only for "project" type templates because it's expecting that these kinds of templates have no their own solution files.

Why does the generating of the Solution file for the "solution" template rely on the type of the Host at all? What is the reason?

BTW, Blazor is a "project" template.

[DamianEdwards]

BTW, Blazor is a "project" template.

Yeah the Blazor template got completely overhauled in .NET 8 AFAIK.

I'm 100% open to making a change here but I wanted to be guided by the experts on the .NET templating side, namely @sayedihashimi and @phenning on what the correct thing to do is to get the desired experience in all environments.

[sayedihashimi]

If I understand correct when this is created in Rider a .sln file is not created because in template.json the type is set to solution and rider expects for the template to create the .sln file. As @khalidabuhakmeh pointed out the issue is caused by

       { 
         "condition": "(hostIdentifier != \"dotnetcli\" && hostIdentifier != \"dotnetcli-preview\")", 
         "exclude": [ 
           "*.sln" 
         ] 
       },

I think the issue can be boiled down to that condition. Here we check for dotnetcli and if it isn't the dotnet cli we essentially assume it's VS or C# Dev Kit. It's probably better for all defaults to be correct for the cli and then to special case VS and C# Dev Kit. So, we can modify the condition to check for those hosts.

There are other options as well, but I'd like to hear from @phenning on what he feels is the best approach here.

[ArtManyak]

Sure, explicit enumeration in this condition should fix the problem. If you really need to change template creation behavior in VS and C# Dev Kit, it's better to use them in this condition.

But I still do not understand why you need to introduce some difference between hosts in case of creating .sln file?

You have a solution template, which should generate a full solution (with .sln file, probably .editorconfig file, etc.). Isn't it risky to rely on the host implementation of creation .sln file? What if once VS will have a bug in this scenario and didn't add all the projects to the .sln?