Skip to content

[BUG] Test Explorer does not pick up code changes after build #1971

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mareklinka opened this issue Apr 30, 2025 · 10 comments
Closed

[BUG] Test Explorer does not pick up code changes after build #1971

mareklinka opened this issue Apr 30, 2025 · 10 comments
Assignees
Labels
Milestone

Comments

@mareklinka
Copy link

Describe the Issue

Recently I noticed that when I make changes to my code and run tests via Test Explorer, the code changes are not reflected in the test run until I manually build my solution - despite the fact that the Test Explorer runs a build before executing the tests.

I noticed a discrepancy in build output paths between my normal build and the build triggered by Test Explorer:
Normal build builds my entire solution and the output path is [project]\bin\Debug\net9.0\[dll]
Test Explorer build builds only the test project and the output path is [project]\bin\x64\Debug\net9.0\[dll] (notice the additional x64 folder in the path).

This seems to cause the problem - because when I look at where Test Explorer looks when doing test discovery, it's [project]\bin\Debug\net9.0\[dll] - without the x64 in the path.

In case this might be relevant, we are using the new SLNX solution format with the following config:

<Solution>
  <Configurations>
    <Platform Name="x64" />
  </Configurations>
  [projects]
</Solution>

The build commands themselves:
Manual: dotnet build Solution.slnx /property:GenerateFullPaths=true /consoleloggerparameters:NoSummary /p:Configuration=Debug /p:Platform="x64"
Test Explorer: dotnet build TestProject.csproj /property:GenerateFullPaths=true /consoleloggerparameters:NoSummary /p:Configuration=Debug /p:Platform="x64"

Steps To Reproduce

No response

Expected Behavior

I would expect that the paths used to build, execute, and discover tests are the same.

Environment Information

Version: 1.99.3 (user setup)
Commit: 17baf841131aa23349f217ca7c570c76ee87b957
Date: 2025-04-15T23:18:46.076Z
Electron: 34.3.2
ElectronBuildId: 11161073
Chromium: 132.0.6834.210
Node.js: 20.18.3
V8: 13.2.152.41-electron.0
OS: Windows_NT x64 10.0.26100

C# Dev Kit 1.19.45

@mareklinka mareklinka added the bug Something isn't working label Apr 30, 2025
@AbhitejJohn AbhitejJohn added the area-test Test discovery, execution, debugging label Apr 30, 2025
@AbhitejJohn AbhitejJohn added this to the May2025 milestone Apr 30, 2025
@ocallesp
Copy link
Member

ocallesp commented May 14, 2025

Adding a repro project
github1971.zip

Repro Steps:

  1. In VS Code, open the github1971 folder.

  2. Wait for the Solution Explorer to load and display the projects.

  3. Right-click on the solution and select Build.

  4. Open the Test Explorer and verify that the existing tests are listed.

  5. Open UnitTest1.cs and add a new unit test.

  6. Return to the Test Explorer and click the Refresh Tests button.

  7. Expected: The newly added test should appear.
    Actual: The new test does not appear in the Test Explorer.

@ocallesp
Copy link
Member

@lifengl in the current scenario, what should be the correct output folder ?

[project]\bin\Debug\net9.0[dll]

or

[project]\bin\x64\Debug\net9.0[dll]

@ocallesp
Copy link
Member

Test Explorer gets the output folder of projects from project queryable space (Project System)

cc: @Jxwoon assigning this issue to Lifeng since CPS owns this service

@ocallesp ocallesp removed the area-test Test discovery, execution, debugging label May 14, 2025
@ocallesp ocallesp removed their assignment May 14, 2025
@Jxwoon Jxwoon assigned Jxwoon and unassigned lifengl May 15, 2025
@Jxwoon
Copy link

Jxwoon commented May 22, 2025

@mareklinka After some investigation, it looks like the issue is due to a missing platform assignment for the individual projects in your .slnx file. Without this explicit mapping, MSBuild falls back to default logic, which can result in output paths like [project]\bin\Debug\net9.0\[dll]

To resolve this, try updating your .slnx file to include a platform mapping for each project, like so:

<Solution>
  <Configurations>
    <Platform Name="x64" />
  </Configurations>
  <Project Path="[Project Path]">
    <Platform Project="x64" />
  </Project>
</Solution>

Please let me know if that works for you!

@Jxwoon Jxwoon closed this as completed May 22, 2025
@mareklinka
Copy link
Author

Thanks for the hint, I now updated the my solution file so that each project has a platform assignment, as you suggested:

<Configurations>
  <Platform Name="x64" />
</Configurations>

<Project Path="project1">
  <Platform Project="x64" />
</Project>
<Project Path="project2">
  <Platform Project="x64" />
</Project>

Now when I build the solution, the build output goes to [project]\bin\x64\Debug\net9.0\[dll]. This resolves the discrepancy between my normal build and the test explorer build. However, now I have a different problem - the Test Explorer is not picking up my tests at all.

I removed all the bin and obj folders manually and reloaded my VSCode. I ran a normal build operation, which produced assemblies in their [project]\bin\x64\Debug\net9.0\[dll] paths. So far, so good. In the Test Explorer output, I see this (the solution contains two test projects):

Created Test Controller
Log verbosity: minimal
Using vstest from dotnet sdk in [C:\Program Files\dotnet\sdk\9.0.300].
Initialized Test Explorer Server [58496]
Test Store Folder: c:\Users\marek\AppData\Roaming\Code\User\workspaceStorage\ee2a53661f2d969346dd051721db6231\ms-dotnettools.csdevkit
Test data store opened in 0.049 sec.
Test controller initialized.
Initialized project system provider.
Waiting for projects to be detected by Project System...
2 projects added, 0 changed, 0 removed.
Assembly not found for discovery: [project1]\bin\Debug\net9.0\[dll]. A build is required.
Assembly not found for discovery: [project2]\bin\Debug\net9.0\[dll]. A build is required.
No runSettingsPath configured. Falling back to default settings.
0 tests discovered from  in 0 ms

As you can see, for some reason, the Test Explorer is still looking for test assemblies in the default folder, not in the x64 folder.

@Jxwoon Jxwoon reopened this May 27, 2025
@Jxwoon
Copy link

Jxwoon commented May 27, 2025

I tried to reproduce the issue on my end but wasn’t able to hit the same behavior.

Here’s what I did:

  1. I manually deleted all bin and obj folders.
  2. Reloaded VS Code. (At this step, I'm seeing the output as you)
  3. Then right-clicked the solution node and ran a build operation.

After the build, I saw the following:

Created Test Controller
Log verbosity: minimal
Using vstest from dotnet sdk in [C:\Program Files\dotnet\sdk\9.0.300].
Initialized Test Explorer Server [39592]
Test Store Folder: [User]\workspaceStorage\0aab5523c5afd8716ada3b546f92253b\ms-dotnettools.csdevkit
Test data store opened in 0.093 sec.
Test controller initialized.
Initialized project system provider.
Waiting for projects to be detected by Project System...
2 projects added, 0 changed, 0 removed.
Assembly not found for discovery: [Project]\bin\Debug\net9.0\[dll]. A build is required.
Assembly not found for discovery: [Project]\bin\x64\Debug\net9.0\[dll]. A build is required.
No runSettingsPath configured. Falling back to default settings.
0 tests discovered from  in 0 ms
Tests are available, running test discovery: [Project]\bin\x64\Debug\net9.0\[dll] [Editor's note: <- this shows up after build]
Scheduling discovery: [Project]\bin\x64\Debug\net9.0\[dll] 
No runSettingsPath configured. Falling back to default settings.
========== Starting test discovery ==========

@mareklinka Could you confirm how you're running the build operation? Are you right-clicking the solution node in Solution Explorer, or are you using the CLI with dotnet build? Also, does clicking the Refresh button in the Test Explorer help trigger test discovery for you?

Edit: Also, please let me know if I'm missing a step here.

@Jxwoon Jxwoon added the needs-more-info Needing more information, waiting on OP label May 27, 2025
@mareklinka
Copy link
Author

I created a trivial minimal repro for this case. Please find it attached.

Without any bells and whistles, just opening the slnx file in VSCode. Hitting ctrl+shift+b and selecting the dotnet: build option produces the following output:

 *  Executing task: dotnet: build 

dotnet build E:\personal\repro-1971\repro-1971.slnx /property:GenerateFullPaths=true /consoleloggerparameters:NoSummary /p:Configuration=Debug /p:Platform="x64" 
  Determining projects to restore...
  All projects are up-to-date for restore.
  project2 -> E:\personal\repro-1971\project2\bin\x64\Debug\net9.0\project2.dll
  project1 -> E:\personal\repro-1971\project1\bin\x64\Debug\net9.0\project1.dll
 *  Terminal will be reused by tasks, press any key to close it. 

Now opening the VSC's command palette and hitting "Developer: Reload Window", this is the output of the C# Dev Kit - Test Explorer pane:

Created Test Controller
Log verbosity: minimal
Using vstest from dotnet sdk in [C:\Program Files\dotnet\sdk\9.0.300].
Initialized Test Explorer Server [19232]
Test Store Folder: c:\Users\marek\AppData\Roaming\Code\User\workspaceStorage\c465d446cbf646bb4bd4e53697de25c0\ms-dotnettools.csdevkit
Test data store opened in 0.006 sec.
Test controller initialized.
Initialized project system provider.
Waiting for projects to be detected by Project System...
1 projects added, 0 changed, 0 removed.
Assembly not found for discovery: E:\personal\repro-1971\project2\bin\Debug\net9.0\project2.dll. A build is required.
No runSettingsPath configured. Falling back to default settings.
0 tests discovered from  in 0 ms

If I go to the Test Explorer and hit Refresh Tests, a build is triggered, producing the following output:

 *  Executing task: dotnet: build E:\personal\repro-1971\project2\project2.csproj 

dotnet build E:\personal\repro-1971\project2\project2.csproj /property:GenerateFullPaths=true /consoleloggerparameters:NoSummary /p:Configuration=Debug /p:Platform="x64" 
  Determining projects to restore...
  All projects are up-to-date for restore.
  project2 -> E:\personal\repro-1971\project2\bin\x64\Debug\net9.0\project2.dll
 *  Terminal will be reused by tasks, press any key to close it. 

So now all the builds output into the same paths, whether they are triggered manually or via the Test Explorer. However, the Test Explorer is still trying to find the assemblies in the incorrect path.

Just in case, extension versions:
C# - 2.79.8
C# Dev Kit - 1.20.14
.NET SDK - 9.0.300
VSCode - 1.100.2 (user setup)

repro-1971.zip

@github-actions github-actions bot removed the needs-more-info Needing more information, waiting on OP label May 27, 2025
Copy link

@Jxwoon, the 'needs-more-info' label has been removed upon receiving further response from the original bug filer.

@Jxwoon
Copy link

Jxwoon commented May 28, 2025

@mareklinka Thanks for providing a repro! Based on it, it looks like you’ll also need to modify the .csproj file. In your example, please open the project2.csproj file and add the following platform mapping: <Platforms>x64</Platforms>

csproj example:

  <PropertyGroup>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <IsPackable>false</IsPackable>
    <Platforms>x64</Platforms>
  </PropertyGroup>

The .csproj file defines what the project itself supports. If x64 isn’t declared there, the project won’t recognize it as a valid build target—even if the solution tries to use it.

Once the platform is added to the .csproj file, the Test Explorer should display the tests.

@mareklinka
Copy link
Author

Thanks for the reply, that did the trick! Now everything seems to in line. Thanks for helping me figure this out!

@Jxwoon Jxwoon closed this as completed May 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants