BaseIntermediateOutputPath & BaseOutputPath are not respected

[ThierryRosseau]

Type: Bug

BaseIntermediateOutputPath & BaseOutputPath are not respected when opening a C# solution in VSCode that is opened for the first time. The bin & obj folders are placed under a subfolder. Not the folder defined in Directory.Build.props file under BaseIntermediateOutputPath & BaseOutputPath tags.

When you build the project this will generate a new bin & obj folder under the correct location but this gives a lot (+20) of exceptions because the incorrect folders still exists :

Duplicate 'global::System.Runtime.Versioning.TargetFrameworkAttribute' attribute
Duplicate 'System.Reflection.AssemblyCompanyAttribute' attribute
...

Extension version: 1.71.4
VS Code version: Code 1.105.1 (7d842fb85a0275a4a8e4d7e040d2625abbf7f084, 2025-10-14T22:33:36.618Z)
OS version: Darwin arm64 25.0.0
Modes:

System Info

Item	Value
CPUs	Apple M4 Pro (14 x 2400)
GPU Status	2d_canvas: enabled direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: enabled_on trees_in_viz: disabled_off video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off
Load (avg)	15, 12, 9
Memory (System)	48.00GB (0.06GB free)
Process Argv	--crash-reporter-id fa4114b9-068b-4ef1-be64-753ef21b0ea7
Screen Reader	no
VM	0%

A/B Experiments

vsliv368:30146709
binariesv615:30325510
nativeloc1:31344060
dwcopilot:31170013
dwoutputs:31242946
copilot_t_ci:31333650
e5gg6876:31282496
pythonrdcb7:31342333
aj953862:31281341
b6b4d950:31327385
nes-set-on:31351930
6abeh943:31336334
aa_c:31379599
gendocstringt:31405074
0574c672:31404437
cloudbuttont:31379625
todos-1:31405332
qwen_all_req:31402696
treatment_gpt5applypatchexclusively:31398171
3efgi100_wstrepl:31403338
trigger-command-fix:31379601
auto_model_enabled:31396818
grok-control-prompt:31401224
use-responses-api:31390855
applesignin:31399435
9i271672:31399627
ddidt:31399633
je187915:31401257
v2prompt_9f72f763:31406505
afag3459:31405348

[claudiaregio]

@ThierryRosseau We think this should be solved with our next release, are you seeing this with the last stable versions of the extensions? C#DK: 1.70.3 , C#: 2.93.22

[ThierryRosseau]

@ThierryRosseau We think this should be solved with our next release, are you seeing this with the last stable versions of the extensions? C#DK: 1.70.3 , C#: 2.93.22

I can confirm this works on the last stable version of C#DevKit and C#. Hopefully this will also work on the next release. Thx

[claudiaregio]

Ok great, I'll keep it open for now. Our next release should be ~Nov 5, when that's out you can let us know if you're still seeing this problem.

[ThierryRosseau]

Still not working on 1.73.14

[LittleLittleCloud]

Not able to reproduce on C#DK 1.73.14 && C# 2.94.41, could you provide more details?

Here's the project to test

Recording.2025-11-04.125508.mp4

[ThierryRosseau]

Hi, I provided a sample with a recording of what happens.

Im currently running on MacOS:

C# : 2.97.38
C# DevKit : 1.73.14

Hope this wil help to find the issue 🤞.

Thx very much

VSCode.zip

[LittleLittleCloud]

@ThierryRosseau Thanks, now I'm able to reproduce this bug based on your example.

To reproduce this bug, adding the following code to Directory.Build.props

<PropertyGroup>
        <BaseIntermediateOutputPath>$(MSBuildProjectDirectory)\tmp-build\obj-windows\</BaseIntermediateOutputPath>
        <BaseOutputPath>$(MSBuildProjectDirectory)\tmp-build\bin-windows\</BaseOutputPath>
    </PropertyGroup>

Then create a new folder, then create a new .cs file under that new folder.

After doing so, you will notice that a tmp-build folder is created under the new folder

I wonder if this bug is relevant to single-file base app, as the assemblyinfo matches the new file name (test.AssemblyInfo.cs) instead of the project. So I wonder if these output files are created when restoring test.cs

[JoeRobich]

@RikkiGibson I know we are setting ArtifactsPath in FBP project loading but it seems that does not override these properties (see props. We should update the virtual project to set the base output paths directly.

[RikkiGibson]

If the issue does not repro with the following setting, it would give us some confidence that file-based programs handling is to blame:

"dotnet.projects.enableFileBasedPrograms": false

[RikkiGibson]

I think we should make a change in the places where we produce "virtual projects", either for "rich misc files", or for file-based apps, so that our ArtifactsPath always wins, so to speak. I think that means including BaseIntermediateOutputPath and BaseOutputPath ourselves explicitly and ensuring it wins over anything that was specified in D.B.props.

When we are doing this we never want to be messing with the user's output directories, either the platform defaults or whatever they have specified for output of their ordinary projects.

Separately, we are working on some changes to ensure that we "reuse" a single virtual project as a basis for both "rich misc files" and potentially "simple" file-based apps, which should also help to ensure that restores are only performed for loose files, in a case where it really makes sense to do so, i.e. #: directives are present or some other very strong indicator that this .cs file is a standalone app.