Just curious, will there be any analyzer or anything that could point out this was added and that any manually added Program declarations can be removed?

I have atonne of these I could delete with this built-in (example), so anything that could point it out rather than me needing to go find them all would be useful 😅

A different idea / approach:

Update the compiler so that it can emit apublic class Program that is configurable via MsBuild-property.
So the default remains the same, when the property is set thepublic class is emitted.
Thus the change here boils down to updating the template csproj.

Or is the process via compiler, sdk, etc. too tedious that this approach is cheaper?

Just curious, will there be any analyzer or anything that could point out this was added and that any manually added Program declarations can be removed?

Oh, good idea! We can definitely author an analyzer + codefix that discovers thepublic partial class Program { } and recommends removing them if you're targeting net10 and above.

Update the compiler so that it can emit a public class Program that is configurable via MsBuild-property.

There was a proposal to change the compiler's behavior to emit a public Program class by default for top-level statements but it was rejected because:

• At the moment, this ASP.NET Core integration testing scenarioseems to be the only one.
• More importantly, there were questions about what the visibility/accessibility of types defined in the generatedProgram class should be.

With those in mind, it was a bit more straightforward for ASP.NET to control its own destiny here and author a source generator.

(Haven't read the code yet)

We also don't want to do this if they'veexplicitly declared it internal, right?

internalpartialclassProgram{}

I'm pretty sure the compilation knows its ownentrypoint, but I'm not sure that's exposed anywhere.

Edit:this might be a useful reference.

We also don't want to do this if they've explicitly declared it internal, right?

Yep, this is another good case to cover in tests. Practically, I don't know how frequently users are doing this since the visibility of theProgram class is alreadyinternal.I suppose it's also possible for somebody to declareprivate partial class Program { }. It's not you can't declareprivate orprotected access in top-level classes.

Edit:this might be a useful reference.

Good reference! I'll incorporate some of the checks here into our code.

I kinda second@gfoidl's question, isn't there a better way to do this, which technically should just be some switch somewhere during project generation or similar, run only once. Instead a source generator which is evaluated more often.

I kinda second@gfoidl's question, isn't there a better way to do this, which technically should just be some switch somewhere during project generation or similar, run only once. Instead a source generator which is evaluated more often.

I started off with this strategy but reached a limitation because there's not a ton of ability to introspect what theProgram class that is already defined looks like. We'd end up generating thepublic partial class Program { } declaration in more situations that is acceptable which might result in surprising behavior.

Also,

some switch somewhere during

I'm assuming you're referring to a switch that the user would set. I'm keen to have this behavior be on-by-default since that moves the needle for this experience a lot more than users having to switch from a declaration in their source code to another switch in their app code.

I'm assuming you're referring to a switch that the user would set.

Yeah, something like the implicit usings setting or something similar, could then even be enabled automatically during project creation, but I understand that's a lot more effort than a src gen. Using MSBuild properties to decide if a srcgen should be executed is also not as straight forward as one might think. I admit, that I don't really see any quick win here.

Merging this now to validate the E2E both perf and functionality wise once it is inserted into the alpha SDK. I'll follow up with building the analyzer after that.