Each test performs building - "dotnet.testWindow.disableBuildOnRun": true not working

[BearCarpenter]

Describe the Issue

since 3.20.195 version each test command (ex. testing.runCurrentFile) build project in my large solution - i have
"dotnet.testWindow.disableBuildOnRun": true

Steps To Reproduce

No response

Expected Behavior

No response

Environment Information

No response

[richardszalay]

FYI you can work around this for now by setting:

"dotnet.testWindow.enableNextTest": false

And then restarting VSCode (or executing Developer: Reload Window)

Alternatively, it may be related to #3171 in which case it might be fixed by the 3.26.1959 pre-release version of the C# Dev Kit extension.

[Quppa]

Appears to be fixed with pre-release version 3.26.195 here.

[Plasma]

Would be fantastic if we have the ability to specify a build task instead of the generated one, for large projects the test runner is unusable due to build times.

[peterwald]

Would be fantastic if we have the ability to specify a build task instead of the generated one, for large projects the test runner is unusable due to build times.

@Plasma The current behavior should be that if you select a test in a single project, it will only build that project and the specific selected target framework (if multiple). So that should theoretically be the smallest set you can rebuild and run the tests. We are looking into ways of determining if we can skip builds in some cases.

If you select multiple projects, it will build each one or if there are enough of them, the entire solution.

What do you envision a custom build task doing in this scenario?

[Plasma]

Thank you @peterwald - at minimum I wish I could just pass a custom build parameter to the build step, a real world example is to pass this custom parameter we have, -p:SkipDesignerFiles=true to the build step. We then make use of this in our EF Core migrations csproj to skip compiling the EF Core designer files:

  <PropertyGroup Condition="'$(SkipDesignerFiles)' == 'true'">
    <DefaultItemExcludes>$(DefaultItemExcludes);Migrations/**/*.Designer.cs</DefaultItemExcludes>
  </PropertyGroup>

The designer files output is so large for us it makes a build step take an extra 60 seconds, so 99% of the time we don't need it built if its not running / creating a migration (dev/test cycles), so when we use the test runner, it causes this extra 60 seconds of build time because there's no way for us to tell the build step to exclude these files from compilation. Our vscode build task always passes this flag, so we get faster builds. We've considered the inverse (eg exclude by default) but then that shifts the problem to another area.

So if possible, a great win would be to be able to pass a custom flag and we can work with this, alternatively the custom build task would work but I can see the former being a quicker win (and actually solves my problem too). At the moment our team has to avoid the test runner (its literally faster for me to ask copilot to run certain tests via test filters via CLI), thanks so much for replying.

[richardszalay]

@Plasma you might be able to pull this off by using adding csharp.unitTestDebuggingOptions to your vscode settings.json to add SkipDesignerFiles as an environment variable since they are used by msbuild to override default property values.

Failing that, you can likely achieve something similar using a .runsettings file, a launch settings, or maybe even a .env file.

[vsccarl]

Status: Fixed