Target net7.0 in additional projects

[lbussell]

These net6.0 target frameworks are still bringing in prebuilts in source-build. They need to be changed before we can ship net7.0 without prebuilts.

[lbussell]

My biggest concern is here: I couldn't find a good reason why this says its pinned. Is there any extra validation I can do to make sure this doesn't break anything?

If absolutely necessary, we can set the TFM to net7.0 for source-build and net6.0;net7.0 otherwise.

[ViktorHofer]

I thought about this change a bit more after our offline discussion and I think we don't want to upgrade the tfm for APICompat projects from net6.0 to net7.0 as they also produce packages which should continue to be consume-able by customers that target net6.0.

I would assume that we only bump the tfm when building via source build.

[lbussell]

@ViktorHofer, so I should amend this PR to conditionally set the TFM to net7.0 for source-build?

Who are the customers of APICompat? If you're concerned about breaking customers, do you think that anyone would be affected if APICompat only targeted net7.0 in source-build (i.e. RHEL and Ubuntu users)?

[ViktorHofer]

Nope. We don't ship packages produced in source build publicly and components inside the stack shouldn't be using any of the ApiCompat packages as ApiCompat itself is already part of the SDK.

Right. It should be fine to only build net7.0 in source build. Alternatively we could always target net7.0 as well but for source build remove the other target frameworks.

[ViktorHofer]

Why do we build net472 when source building?

[lbussell]

We try to keep source-build as close to the product build as possible. If we don't lose anything by dropping net472 here, I'm fine with removing it though.

[lbussell]

@tmat Do you know what might be going wrong with the dotnet watch tests here? Might I be getting a path wrong somewhere?

[tmat]

No, the tests are flaky. Fix is on the way: #27700

[lbussell]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[lbussell]

@tmat Can you take another look? I cherry picked your changes and the newest test failure is a timeout:

  Starting:    dotnet-watch.Tests
Running C:\h\w\A5F208B3\p\d\dotnet.exe msbuild /t:Build C:\h\w\A5F208B3\t\dotnetSdkTests\54nv1kzn.mfo\RunsWithDotne---807F2E9B\WatchKitchenSink.csproj /restore
Process ID: 3172
Running C:\h\w\A5F208B3\p\d\dotnet.exe msbuild /t:Build C:\h\w\A5F208B3\t\dotnetSdkTests\54nv1kzn.mfo\RunsWithItera---4AD8E626\WatchKitchenSink.csproj /restore
    Microsoft.DotNet.Watcher.Tools.DotNetWatcherTests.Run_WithHotReloadEnabled_ReadsLaunchSettings_WhenUsingProjectOption [SKIP]
      https://github.com/dotnet/sdk/issues/24406
Process ID: 5172
    Microsoft.DotNet.Watcher.Tools.DotNetWatcherTests.RunsWithRestoreIfCsprojChanges [SKIP]
      https://github.com/dotnet/aspnetcore/issues/23854
Running C:\h\w\A5F208B3\p\d\dotnet.exe msbuild /t:Build C:\h\w\A5F208B3\t\dotnetSdkTests\54nv1kzn.mfo\Run_WithHotRe---4C2010FF\WatchAppWithLaunchSettings.csproj /restore
Process ID: 4352
['dotnet-watch.Tests.dll.1' END OF WORK ITEM LOG: Command timed out, and was killed]

The original error was unrelated to timeouts:

�[m�[37m        9/6/2022 7:23:43 PM: post: 'Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=7.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.'
�[m�[37m        9/6/2022 7:23:43 PM: post: ''
�[m�[37m        9/6/2022 7:23:43 PM: post: 'File name: 'System.Runtime, Version=7.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a''
�[m�[37m        9/6/2022 7:23:43 PM: post: '   at System.Reflection.RuntimeAssembly.GetType(QCallAssembly assembly, String name, Boolean throwOnError, Boolean ignoreCase, ObjectHandleOnStack type, ObjectHandleOnStack keepAlive, ObjectHandleOnStack assemblyLoadContext)'
�[m�[37m        9/6/2022 7:23:43 PM: post: '   at System.Reflection.RuntimeAssembly.GetType(String name, Boolean throwOnError, Boolean ignoreCase)'
�[m�[37m        9/6/2022 7:23:43 PM: post: '   at System.Reflection.Assembly.GetType(String name, Boolean throwOnError)'
�[m�[37m        9/6/2022 7:23:43 PM: post: '   at System.StartupHookProvider.CallStartupHook(StartupHookNameOrPath startupHook)'
�[m�[37m        9/6/2022 7:23:43 PM: recv: 'Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=7.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.'. Does not match condition '[msg == 'Echo: This is a test input']'.

I'm trying to figure out why only these dotnet watch tests are unable to find System.Runtime, I suspect it is because of the paths I changed.

[tmat]

The same issue, see the dump:

Could not load file or assembly 'System.Runtime, Version=7.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.

>	System.Private.CoreLib.dll!System.Reflection.RuntimeAssembly.GetType(string name, bool throwOnError, bool ignoreCase) Line 197	C#
 	System.Private.CoreLib.dll!System.Reflection.Assembly.GetType(string name, bool throwOnError) Line 109	C#
 	System.Private.CoreLib.dll!System.StartupHookProvider.CallStartupHook(System.StartupHookProvider.StartupHookNameOrPath startupHook) Line 141	C#
 	System.Private.CoreLib.dll!System.StartupHookProvider.ProcessStartupHooks() Line 104	C#

[lbussell]

I cherry picked #27766 and #27700 which should hopefully get around the test failures for now.

[lbussell]

@ViktorHofer, @ericstj, @tmat, can you all review this? We wouldn't like to carry this as a source-build patch beyond RC2 as it can cause conflicts and block CI.

[tmat]

I can't think of why the Delta Applier needs to be net6.0 either. It is loaded into the target application by dotnet-watch, but the app should run on the same .NET version as dotnet-watch does so even if the app targets net6.0 the Delta Applier should be able to call net7.0 .NET API.

[ViktorHofer]

The APICompat changes LGTM.