Visual Studio does not retain 'Do not use top-level statements' check.

[TanvirArjel]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

First of all, thank you ASP.NET Core Team for adding an option in templates to avoid top-level statement.

However, we have noticed that Visual Studio is not retaining the Do not use top-level statement check.

First Time:

Second Time:

Note: All other checks are retaining their last choice.

Expected Behavior

Check should retain the last choice.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

6.0.300 and 7.0.100-preview.4.22252.9

Anything else?

Visual Studio Version: 2022 17.3 preview 1.

[TanayParikh]

cc/ @DamianEdwards as I believe this was recently added.

[mkArtakMSFT]

This seems to be a feedback for VS, isn't it ?

[TanvirArjel]

@mkArtakMSFT Is it not part of templating? However, please redirect to the appropriate channel.

[DamianEdwards]

@phenning

[phenning]

We don't by default save the previous choice of any "custom" parameters. Custom here meaning anything below the Docker choices in the UI.

Templates must opt into this explicitly. We do have some mechanisms where we can override this in Visual Studio, or it can be done directly in the host file. @DamianEdwards I'll ping you offline to see how we want to approach this.

[DamianEdwards]

Details for the change we need to make to the ide.host.json for each web project template, including the console template, in 7.0:

{
  "id": "UseProgramMain",
  "isVisible": true,
  "PersistenceScope": "Shared",
  "PersistenceScopeName": "Microsoft"
}

@phenning is going to ensure that once we make this change in 7.0, any customer with both 6.x and 7.0 installed will see this option become sticky for all versions of the template available, i.e. it will become sticky in 6.x templates too.

/Cc @vlada-shubina

[TanvirArjel]

Hello @DamianEdwards , Here is another issue: #41636

[DamianEdwards]

Thanks, that's a known issue that we're currently working on getting a fix in to 7.0 and 6.0 for (#41491).

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[TanvirArjel]

@DamianEdwards I have checked with .NET SDK 6.0.7 and 7.0.0 preview6 with Visual Studio 2022 version 17.3 Preview 3. The issue has not been fixed.

[phenning]

@DamianEdwards I was looking at another related issue this morning and saw this, so I took a look. It looks like Preview 3 did not have the 7.0.0 preview6 version that had this change. It looks like 7.0.100-preview.6.22352.1 SDK does have the fix though.

[DamianEdwards]

Yeah this fix is in the 7.0 SDK and thus will only apply to 6.0 projects when 7.0.100-preview.6 is installed. VS 17.4 will default to including .NET 7 SDK at which point this will be fixed for 6.0 projects too.