[dougbu]

• remove Microsoft.NET.Test.Sdk version override
• new vstest.console.dll in the .NET SDK is again compatible w/ older testhost.dll in the Test SDK

[MarcoRossignoli]

LGTM

[dougbu]

This PR didn't test on Arm64 (Windows or Linux). I should instead of just used the branch in a run of our aspnetcore-helix-matrix pipeline.

But, looking at the consistent failures in this trial, I doubt that's worthwhile. The newer SDK seems to introduce a bug in dotnet tool and it's not able to install dotnet-ef at version 7.0.0-alpha.1.21568.2:

Unhandled exception: System.ArgumentException: Version string portion was too short or too long. (Parameter 'input')

@dsplaisted who should we contact about that problem❔ @MarcoRossignoli and I were just trying to see if the new test bits in the .NET SDK were compatible w/ the 16.x Test SDK. Hit this first ☹️

[dsplaisted]

Where is that error message coming from and what's the stack trace? Looking at the CI failures currently, I only see a different message:

System.ComponentModel.Win32Exception : An error occurred trying to start process 'dotnet-ef' with working directory 'C:hwA35C090EwAF8C093BeTemplatesBaseFolderAspNet.mlxmrxruasmServer'. The system cannot find the file specified.

[dougbu]

@dsplaisted plz look near the top of the console log, where the test infrastructure executes dotnet tool install dotnet-ef .... The stack trace seems consistent across platforms and affects both 'C:\h\w\A35C090E\p\dotnet-cli/dotnet tool install dotnet-dump --tool-path C:\h\w\A35C090E\w\AF8C093B\e --version 5.0.0-*' and 'C:\h\w\A35C090E\p\dotnet-cli/dotnet tool install dotnet-ef --version 7.0.0-alpha.1.21568.2 --tool-path C:\h\w\A35C090E\w\AF8C093B\e' completed with exit code '1'.

Unhandled exception: System.ArgumentException: Version string portion was too short or too long. (Parameter 'input')
   at System.Version.ParseVersion(ReadOnlySpan`1 input, Boolean throwOnFailure)
   at System.Version.Parse(String input)
   at System.Version..ctor(String version)
   at Microsoft.DotNet.Tools.Tool.Install.ToolInstallGlobalOrToolPathCommand.<>c.<Execute>b__17_1(NuGetFramework f)
   at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
   at System.Linq.Enumerable.MaxBy[TSource,TKey](IEnumerable`1 source, Func`2 keySelector, IComparer`1 comparer)
   at Microsoft.DotNet.Tools.Tool.Install.ToolInstallGlobalOrToolPathCommand.Execute()

I was wrong in thinking the problem was specific to Linux and macOS. The above commands are from a Windows console log for the failing work item.

[dsplaisted]

@sfoslund Can you take a look at this tool install issue? (Assuming you own dotnet tools now, which I think is the case). It looks like it doesn't like --version 5.0.0-*, which I guess used to work.

[dougbu]

It looks like it doesn't like --version 5.0.0-*, which I guess used to work.

Doesn't like --version 7.0.0-alpha.1.21568.2 much either.

[sfoslund]

Can you take a look at this tool install issue? (Assuming you own dotnet tools now, which I think is the case). It looks like it doesn't like --version 5.0.0-*, which I guess used to work.

@joeloff owns tools now, but I have bandwidth to take a look if he needs. Although it looks like he's already fixing a similar issue: dotnet/sdk#22684, @joeloff is this the same bug or a different one?

[joeloff]

This looks similar to what I'm fixing in 6.0.2xx dotnet/sdk#22684

[wtgodbe]

This should have the fix we need: dotnet/installer#12716

[dougbu]

Trying it all again w/ the 7.0.100-alpha.1.21574.8 SDK (which includes @joeloff's fix)

[dougbu]

Is it dotnet/installer that populates https://dotnetbuilds.azureedge.net❔

dotnet-install: Downloading primary link https://dotnetbuilds.azureedge.net/public/Sdk/7.0.100-alpha.1.21574.8/dotnet-sdk-7.0.100-alpha.1.21574.8-linux-x64.tar.gz
curl: (22) The requested URL returned error: 404 

[dougbu]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[dougbu]

Getting further from an actual test; likely need dotnet/sdk#22668 to merge before dotnet/installer#12716 will work ☹️

[dougbu]

If we get a usable SDK / installer build containing @MarcoRossignoli's fix, this branch is also available at https://github.com/dotnet/aspnetcore/tree/dougbu/remove.override i.e. there's no need for anyone else to update my fork. Not creating a new PR using the non-fork branch because work here remains blocked.

[wtgodbe]

Whoops, updated this too early. Next installer build should have the fix we need: https://dev.azure.com/dnceng/internal/_build/results?buildId=1499097&view=results