Add usings back to Blazor client Program.cs

[DamianEdwards]

BlazorWasm SDK hasn't got implicit global usings as yet so they need to be included for now.

Successfully ran the BlazorWasm template and ProjectTemplates.Tests passed locally.

@captainsafia @davidfowl

[lewing]

So how did this all get broken in the way it did?

[davidfowl]

So how did this all get broken in the way it did?

That's the real question. Turns out these tests are quarantined and they don't fail the build?

[DamianEdwards]

@lewing what @davidfowl said. The template tests don't fail CI and this one file got missed.

[lewing]

one file? 👎

[DamianEdwards]

And by "missed" I mean "included when it shouldn't have been" 😐

[lewing]

So how do we avoid this kind of oversight breaking things for days in the future?

[DamianEdwards]

@lewing not sure what you're referring to in this case, my change went in yesterday evening. At any rate, something to take up with @dotnet/aspnet-build. I'd certainly appreciate any change that catches template issues at the stage they're in PR to this repo.

[davidfowl]

@HaoK and @dougbu have some opinions here.

cc @mkArtakMSFT @Pilchie as an FYI because I agree with @lewing this should fail the build. Apparently there's some history here with flaky template tests being disabled and the build passes as a result even when it fails.

[HaoK]

I think we should probably add back the equivalent of the build/publish only versions of the blazor templates just like the other templates, and leave the playwright enabled version in quarantine that is doing more verification than the other templates, so at least blazor templates have parity with the other templates and we don't have this gaping hole. I can probably whip something together on monday in a PR

[HaoK]

#34275 the blazor template tests are failing in the PR with missing using errors, just making sure that these are the failures we should be expecting to see in main right now?

 | [20.973s] Templates.Test.BlazorWasmTemplateTest Information: /datadisks/disk1/work/A4A108F8/w/B08209BB/e/Templates/BaseFolder/AspNet.4gejuehuxut/Program.cs(7,18): error CS1061: 'IServiceCollection' does not contain a definition for 'AddScoped' and no accessible extension method 'AddScoped' accepting a first argument of type 'IServiceCollection' could be found (are you missing a using directive or an assembly reference?) [/datadisks/disk1/work/A4A108F8/w/B08209BB/e/Templates/BaseFolder/AspNet.4gejuehuxut/AspNet.4gejuehuxut.csproj]
 | [20.973s] Templates.Test.BlazorWasmTemplateTest Information: /datadisks/disk1/work/A4A108F8/w/B08209BB/e/Templates/BaseFolder/AspNet.4gejuehuxut/Program.cs(9,18): error CS1061: 'IServiceCollection' does not contain a definition for 'AddMsalAuthentication' and no accessible extension method 'AddMsalAuthentication' accepting a first argument of type 'IServiceCollection' could be found (are you missing a using directive or an assembly reference?) [/datadisks/disk1/work/A4A108F8/w/B08209BB/e/Templates/BaseFolder/AspNet.4gejuehuxut/AspNet.4gejuehuxut.csproj]

[davidfowl]

Yep!

[SteveSandersonMS]

@davidfowl

Apparently there's some history here with flaky template tests being disabled and the build passes as a result even when it fails.

That's very much correct. It also applies to all the other browser automation tests that we have. Despite probably hundreds of hours of work trying to make them "reliable" in CI, we haven't got any closer over time. If anything, we've got further from the goal over time. I no longer believe it's a defect in the tests, but rather a mixture of (1) the infrastructure needing to be much less resource constrained because actual browsers don't perform with extreme resource shortages, and (2) us stopping thinking of UI automation as just another kind of unit test, as they just aren't.

[DamianEdwards]

This PR is likely not needed anymore as @davidfowl's change to the SDK should negate the need for it.