!fixup! Remove more WebAssembly template mentions

[dougbu]

• follow up to part of b6c411f
  • more dangling references to a non-existent project

[dougbu]

Would expect to hit problems continuously since 6c16632 went in in February (v3.1.13). But, change didn't reliably cause

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1947,5): warning : The referenced project '../ComponentsWebAssembly.ProjectTemplates/Microsoft.AspNetCore.Components.WebAssembly.Templates.csproj' does not exist. [D:\workspace\_work\1\s\src\ProjectTemplates\test\ProjectTemplates.Tests.csproj]

all the time. Has occurred in official builds e.g.

• https://dev.azure.com/dnceng/internal/_build/results?buildId=1134884&view=logs&j=f43b187f-6c15-531c-a59b-e4fba4e9ed20&t=9e357cb9-1774-5509-1b39-7d8136be93e2&l=2609
• https://dev.azure.com/dnceng/internal/_build/results?buildId=1148164&view=logs&j=6c33d704-163a-5170-38fa-caa7bc99f17c&t=a59c73d3-09b1-5a7e-4e53-9d83598ad56e&l=3067
• https://dev.azure.com/dnceng/internal/_build/results?buildId=1148167&view=logs&j=6c33d704-163a-5170-38fa-caa7bc99f17c&t=a59c73d3-09b1-5a7e-4e53-9d83598ad56e&l=3109
• https://dev.azure.com/dnceng/internal/_build/results?buildId=1182552&view=logs&j=366a1024-3a8a-5d08-6c00-a4b17dce0d38&t=7c220d1f-55ee-5c39-b8a6-7373cb0d28ee&l=1565

[dougbu]

@mmitche @wtgodbe (or 3.1.17 CQB if neither of you) should we get this into v3.1.17❔

[dougbu]

@Pilchie I'm thinking tell-mode for either v3.1.17 (if we have time) or v3.1.18. Your thoughts❔

[Pilchie]

👍🏻 for tell-mode

[dougbu]

@dotnet/aspnet-build I'm hesitant to merge this due to the failures in https://dev.azure.com/dnceng/public/_build/results?buildId=1184332&view=results I think I've seen similar problems in other release/3.1 builds but am not positive. The binary log is also 429 MB and is still opening on my machine. Anyone seen this before❔ Any objections to retrying the failed job❔

@rainersigwald any suggestions you have would of course be much appreciated❕

Oddly, the following seemed to occur while desktop msbuild was shutting down after a successful build:

Microsoft.Build.Shared.InternalErrorException: MSB0001: Internal MSBuild Error: We shouldn't be accessing the ProjectInstance when the configuration is cached.

[dougbu]

/btw ping reviewers 😺

[dougbu]

Binary log finished opening as I submitted the previous comment (of course). No indication of any problems beyond our usual "double writes" of a few blah.sourcelink.json files and two copies of xunit.abstractions.dll. (Unrelated question: Are the double writes anything we should be working to fix❔ If so, what's the recommended fix❔)

[rainersigwald]

That error is dotnet/msbuild#6436 which is fixed in 16.9.7 and 16.10.0. Unfortunately, Arcade updates obliterated the workaround 75b7808. You should probably pick that back up until you can update the toolset.

[ryanbrandenburg]

Seems OK to me, though I'm not plugged into this work anymore.

[dougbu]

Unfortunately, Arcade updates obliterated the workaround 75b7808. You should probably pick that back up until you can update the toolset.

Either we must get the workaround into the Arcade SDK or we should update the toolset -- soon. Which toolset did you mean @rainersigwald❔

In the meantime, I'll retry the failing job…

[rainersigwald]

Which toolset did you mean @rainersigwald Rainer Sigwald FTE❔

The Visual Studio version installed on your worker machines, I believe.

[dougbu]

The Visual Studio version installed on your worker machines, I believe.

According to the VS2019 Upgrade Schedule (see Core-Eng rollout emails), the agents are at 16.9.5 and will stay that way for at least a week. I doubt switching to the .Pre build agents would be enough (they're at 16.10.0 Preview 3) and we'd only be able to use "scouting" agents (at 16.10.0) in public builds. Scouting pool for public builds won't be enough because we run about the same stuff (or more) in our internal builds of 'release/3.1'. Ah well…

I'm not thrilled about updating eng/common/ files outside an Arcade update but will do that if the next retry fails (too).

@markwilkie @ilyas1974 @MattGal the workaround we had basically switched to use the 64-bit msbuild when using desktop msbuild. Would Core-Eng object to a switch enabling that going forward in your release/3.x branch❔ A "yes" would make me happier about re-enabling our local hack for now.

[ilyas1974]

I don't see a problem with adding a switch to use the 64bit version of msbuild, but I will defer to the others on my team on that question. Another option is to bring the VS 16.10.0 image "forward" into the release queue early. If that is something that is needed, we can contact Tactics and get their by-off.
cc: @tkapin

[rainersigwald]

Another option is to bring the VS 16.10.0 image "forward" into the release queue early.

Note that there's a few bugs that have affected external customers in MSBuild 16.10.0 -- ideally we'd roll out directly to 16.10.2 to avoid hitting those for dotnet teams. Arcade keeps folks from hitting the biggest bug fixed in 16.10.1, but some of the .2 content might be relevant.

I don't see a problem with adding a switch to use the 64bit version of msbuild

Adding a switch should be fine; doing it by default is riskier since some (incorrectly authored) tasks don't work in a 64-bit MSBuild environment. I'd be fine changing the default to 64-bit in Arcade 6 but in servicing it's not my favorite idea.

[wtgodbe]

If this fixes any transient build failures & it's green today then we can take it for July, otherwise let's hold until August

[dougbu]

I hacked around the problem by disabling the Windows x86 binary log. That may be enough between now and when we move to a recent-enough VS installation or I add the Arcade switch.

I see dotnet/aspnetcore's later branches don't create binary logs for Windows x86. So maybe this hack is enough❔

I'd like to make the Arcade change everywhere anyway because it seems likely to improve build performance, even though binary logs are smaller in 6.0. (Is that valid @rainersigwald❔) At least dotnet/aspnetcore's other branches are less pressing because they do less in a single msbuild invocation e.g. doing more with dotnet msbuild (separating the native builds) and not building test projects in many build steps (including the one that's fairly consistently failing here). Thoughts❔

[rainersigwald]

I hacked around the problem by disabling the Windows x86 binary log

What makes you think the binlog is related here? I wouldn't expect it to be a major factor.

I'd like to make the Arcade change everywhere anyway because it seems likely to improve build performance, even though binary logs are smaller in 6.0. (Is that valid @rainersigwald Rainer Sigwald FTE❔)

Binary logs got smaller in 16.10 but haven't significantly changed (yet) for 17.0. Performance-wise, 32- versus 64-bit MSBuild might make a difference if the "paging" approach we take is actually costing you significant time--but it often doesn't, and there are risks of switching to 64-bit in terms of functionality, which is why I don't recommend switching to it everywhere in servicing. Probably a great idea to do so for Arcade 6 though.

[dougbu]

I hacked around the problem by disabling the Windows x86 binary log

What makes you think the binlog is related here? I wouldn't expect it to be a major factor.

Well, my hack failed in any case. I thought it would help because dotnet/msbuild#6436 mentions memory pressure and binary logs are certainly not free.

which is why I don't recommend switching to it everywhere in servicing

Agreed. I wasn't proposing anything other than an off-by-default switch we could try using in this repo.

[dougbu]

https://dev.azure.com/dnceng/public/_build/results?buildId=1189546&view=results built successfully though that's not reflected here. Getting this in…