Bug - Defaulting $(Platform) to Any CPU causes tests to hang indefinitely / time out.

[cmeyertons]

Background and Motivation

I was piloting Aspire into a new proof-of-concept service at our organization and ran into this issue.

In our company's application template, we have a custom Directory.Build.props file etc etc.

Out of the box:
✔️ The application runs and debugs seamlessly!
❌ The tests hang indefinitely

After some (much) process of elimination, the culprit is defaulting the <Platform> to Any CPU 🤔

Steps to reproduce

1. Create a solution using the Aspire Starter Application with the following options

• - Configure for HTTPS
• - Use Redis...
• - Create a test project

2. Build & run the tests, observe everything passes.
3. Add a Directory.Build.Props to the solution root with the following:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <Platform Condition=" '$(Platform)' == '' ">Any CPU</Platform>
  </PropertyGroup>
</Project>

⚠️ Yes, the above is probably not needed and came way before my time. I can easily remove the offending line, but figured I would escalate this to the team as it gave me trouble and hope to not have others fall into the same trap😅

4. Observe the tests now hang indefinitely and time out.

Expectation

I would expect this behavior to:

1. not happen at all (i'm not sure why it's happening, i did some cursory looking at the Aspire code and nothing jumped out)
2. consistently happen when running the application vs testing 🤷‍♂️

[cmeyertons]

Additionally, modifying the OutputPath has the same effect.

<PropertyGroup>
  <SolutionDir Condition="$(SolutionDir) == ''">$(MSBuildThisFileDirectory.TrimEnd('\').TrimEnd('/'))\</SolutionDir>
  <OutputPath>$(SolutionDir)artifacts\bin\$(Configuration)\$(MSBuildProjectName)</OutputPath>
</PropertyGroup>

It seems like monkeying with some settings confuses the Aspire test engine somehow.

Confirmed confusers:

• Platform
• OutputPath

Confirmed okay (that i'm surprised don't have the same effect):

• TargetFramework
• AssemblyName
• AppendTargetFrameworkToOutputPath
• AppendRuntimeIdentifierToOutputPath
• BaseIntermediateOutputPath

[davidfowl]

@joperezr can you take a look?

[joperezr]

Hello @cmeyertons, thank you so much for logging the issue and for the detailed report. Could you confirm which version of Aspire you are using by running dotnet workload list or checking which version of the Hosting package you are referencing in your AppHost project?

My hunch just by reading your (very detailed 😃) report, is that you may be running into #3939, which would be likely if the version you are using is 8.0.1 or earlier. This issue has been fixed in 8.1.0 previews but we haven't released those yet to NuGet.

A quick summary of why I think this is the root cause, is that in order for the app host to launch your services (resources) it uses some assembly attributes that make some assumptions of where to find some executables required to run your app and your tests. I believe what may be going on is that by some of these changes you are making in configuration, some of those assumptions may be invalid and therefore causing an issue.

[cmeyertons]

Obviously not detailed enough because I didn't include the Aspire version lol

I'm on 8.0.0 (just pulled from the VS template), so that adds up.

[joperezr]

Thanks for confirming. One more question, how are you running your tests? I'm able to repro when running from command line, but not from VS, and also I'm able to repro only if I run dotnet test on the sln, but not on the test project, so I wonder if you are seeing the same

[cmeyertons]

I’m using the JetBrains Resharper Unit Test runner inside VS.

[mitchdenny]

Does the Apphost crash if you run it? @ReubenBond also fixed some code in the testing side of things where if the AppHost crashes at certain points the test infrastructure will hang.

[cmeyertons]

No app host runs fine (unless it's not obvious if it crashes while debugging). I can hit the /weatherforecast endpoint and it just spins forever until it times out.

[DamianEdwards]

Putting this in 8.1 as we suspect it's a dupe of #3939 but should verify upon release.

[danmoseley]

@cmeyertons 8.1 will be out by end of july, if you have a chance to verify in that it would be great.