For some reason, many tests are trying to resolve a 9.0 runtime on osx/linux. I wonder if its because 10 is not available.

Expected command to exit with 0 but it did not.\nFile Name: dotnet\nArguments: Microsoft.TemplateSearch.TemplateDiscovery.dll --basePath /var/folders/kk/yc0qf4694xl1_d6sqg40_2sr0000gn/T/TemplateEngine.Tests/b5928f77-2832-40e4-9657-bfe6ad27571f --packagesPath /var/folders/kk/yc0qf4694xl1_d6sqg40_2sr0000gn/T/TemplateEngine.Tests/c4674323-e566-4957-acca-62344b8a50e1/packages -v --diff false\nExit Code: 1\nStdOut:\n\nStdErr:\nUnhandled exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.\n\nFile name: 'System.Runtime, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'\n   at Microsoft.TemplateSearch.TemplateDiscovery.Test.TestPackCheckerFactory.LoadExistingCache(CommandArgs config)\n   at Microsoft.TemplateSearch.TemplateDiscovery.Test.TestPackCheckerFactory.CreatePackSourceCheckerAsync(CommandArgs config, CancellationToken cancellationToken) in /Users/runner/work/1/s/tools/Microsoft.TemplateSearch.TemplateDiscovery/TestProvider/TestPackCheckerFactory.cs:line 36\n   at Microsoft.TemplateSearch.TemplateDiscovery.TemplateDiscoveryCommand.ExecuteAsync(CommandArgs config, CancellationToken cancellationToken) in /Users/runner/work/1/s/tools/Microsoft.TemplateSearch.TemplateDiscovery/TemplateDiscoveryCommand.cs:line 137\n   at Microsoft.TemplateSearch.TemplateDiscovery.TemplateDiscoveryCommand.<.ctor>b__14_1(ParseResult parseResult, CancellationToken cancellationToken) in /Users/runner/work/1/s/tools/Microsoft.TemplateSearch.TemplateDiscovery/TemplateDiscoveryCommand.cs:line 125\n   at System.CommandLine.Invocation.InvocationPipeline.InvokeAsync(ParseResult parseResult, CancellationToken cancellationToken)\n

At first, I thought mariner-2 maybe dropped .net 9 support and we switched to new image runners.
But then I realized we've been using that for a year.

Then I tried to set NetMinimum in directory.build.props to .NET 10. But I didn't see that property propagate, and some of TE still builds on .NET 8. I don't have the context as to why. FYI @dotnet/templating-engine-maintainers

Instead, I've tried to make it so .NET 9 is installed via the pipeline to see if this makes it so it can find the .NET 9 runtime.

It's still failing to load .NET 9.

It's also got an authoring issue:

/Users/runner/work/1/s/.packages/microsoft.templateengine.authoring.tasks/10.0.100-preview.4.25220.1/build/Microsoft.TemplateEngine.Authoring.Tasks.targets(25,5): Template configuration message MV005: Missing 'sourceName'. [/Users/runner/work/1/s/template_feed/Microsoft.TemplateEngine.Authoring.Templates/Microsoft.TemplateEngine.Authoring.Templates.csproj]

Surprisingly, the tests work on my linux machine without .net 9.0. I haven't been able to reproduce this yet.

The issue is in LoadExistingCache. I wonder if it's trying to use a .NET 9 based cache.

I'm going to try to refresh or stop this cache in the CI machine so we can evaluate my hypothesis. If my hypothesis is true, I think we should consider filing this as a potential code issue.

I have higher confidence because this has happened before https://github.com/dotnet/templating/pull/8952/files and #9052

Now, what I don't yet know is how NetCurrent is set.

Some dark magic sets it to 10.0. Net Previous is 9 while minimum is 8. I think we should consider this.

TargetFrameworkDefaults from arcade.sdk sets all of these values. I'm wondering if this is a break from arcade.

Prior to codeflow:
https://github.com/dotnet/dotnet/blob/02dfa783c1/src/arcade/src/Microsoft.DotNet.Arcade.Sdk/tools/TargetFrameworkDefaults.props

current: 10
prev: 9
min: 8

Post:
https://github.com/dotnet/dotnet/blob/115a295775/src/arcade/src/Microsoft.DotNet.Arcade.Sdk/tools/TargetFrameworkDefaults.props

It's the same :/ So, I imagine this is an issue with the cache not working due to a rollout of .NET.

@copilot undo my changes in ada559b as they don't matter.

@nagilson I've opened a new pull request, #9627, to work on those changes. Once the pull request is ready, I'll request review from you.

Ugh, nvm.

@dotnet/templating-engine-maintainers It seems like the template cache is broken. It's trying to rely on .NET 9. I'm thinking it's got some cached values and now it's trying to load something it shouldn't. #9052 seemed to track this in the past.

I don't know if you want to disable the cache in the tests only, disable it in code because it's got a bug, or try to fix the bug for .NET 10. Either way, hopefully this research and context I did helps.

TemplateSearch package is built against .net 8 from what I can tell, at least based on what I downloaded from the pipeline

Based on what I'm seeing, the deps.json shows that it target 8.0, but has a dependency on logging abstractions from 9.0.3, this might be the cause of the problem.

@nagilson I'm testing out a fix in another branch

Thank you.

@ViktorHofer I think we should be good here, but I wanted to alert you to the change we're making going back to NetCurrent over NetMinimum, compared to what we did here: #8952 to properly enforce our tests build/run on .NET 10.

I don't anticipate this impacting NET framework tasks, but if you disagree please let me know

TFM changes aren't something that we do in servicing. That would require an ask mode template as it could break customers.

I suggest to revert this change. This really doesn't look right. Especially in servicing. This also goes on what we agreed on in Tactics a while ago. These nuget packages should support the minimum version of .NET in support (for .NET 10 released packages that is .NET 8). Bumping to .NET 10 locks out customers from adopting the latest versions.

I suggest to revert this change. This really doesn't look right. Especially in servicing. This also goes on what we agreed on in Tactics a while ago. These nuget packages should support the minimum version of .NET in support (for .NET 10 released packages that is .NET 8). Bumping to .NET 10 locks out customers from adopting the latest versions.

The package as it stands today is simply incorrect. 8.0.xxx always had 8.0 dependencies, 9.0.xxx had 9.0 runtime dependencies. 10 having 8.0 dependencies doesn't make sense and I don't see how that blocks people from adopting 10.0. In fact, we'd be targeting a TFM that will be out of support while 10 is still in support.

It seems this was the original PR that reverted the TFMs: #8952

@ViktorHofer I was looking at other packages like Microsoft.Extensions*. They are targeting 8, 9 and 10. Is that perhaps the pattern we should use here?

Happy to follow up offline