Change API template to only use Invariant Globalization in Native AOT…

[mitchdenny]

Addresses #48186

I don't think we want to make it painful for people using the API template when they aren't doing native AOT. Longer term I think SqlClient will need to figure out how to work with invariant globalization. I think this provides a gradual ramp for folks where we get the size benefits for an AOT project out of the box - but if they want to use SqlClient then they need to opt into globalization so it can work (but non native AOT folks don't even need to consider it).

[Varorbc]

Not only Api templates, but also Grpc and worker templates

[eerhardt]

I don't believe we should be making this change.

See the discussion in #47029. This was done intentionally outside of "AOT" because "API server applications often don't need to consider culture behavior".

There are 2 mitigations here:

1. SqlClient should work correctly in InvariantGlobalization mode. This mode is becoming more popular, and so SqlClient should work in it.
2. Until that time, people can just remove the InvariantGlobalization line in their .csproj if they are using SqlClient.

[Varorbc]

1. SqlClient should work correctly in InvariantGlobalization mode. This mode is becoming more popular, and so SqlClient should work in it.

Is it possible to communicate between the two teams to solve this issue?

[eerhardt]

Is it possible to communicate between the two teams to solve this issue?

Thoughts, @ajcvickers @roji @AndriySvyryd ?

[ajcvickers]

@David-Engel owns SqlClient.

[David-Engel]

1. SqlClient should work correctly in InvariantGlobalization mode. This mode is becoming more popular, and so SqlClient should work in it.

Is it possible to communicate between the two teams to solve this issue?

Applications expect things to be translated correctly to/from a database. Culture information is an integral part of that, particularly for non-English cultures.

At the risk of getting bashed here, how many SqlClient users actually rely on globalization information without realizing it? I don't think the cost to "make SqlClient work" in globalization-invariant mode would be worth the cost in dev/test time, support time, and end-user troubleshooting time, when things don't work quite right and people end up having to enable it anyway. It's a deep dive we don't have the bandwidth for.

[mitchdenny]

I think @David-Engel raises a fair point. IMHO we should disable global invariant mode when we aren't in AOT mode (where size might be a motivating issue and folks might be less likely to be using SQL Client). I think it strikes a good compromise for where we are now.

[eerhardt]

Thanks!

[eerhardt]

Looks like this needs to be updated:

aspnetcore/src/ProjectTemplates/test/Templates.Tests/WorkerTemplateTest.cs

Line 61 in b441d4e

await project.VerifyHasProperty("InvariantGlobalization", "true");