Feature Request: Disable MSBuild automatic creation of obj & bin folders

[guardrex]

Opened from comment (omnisharp-vscode #1272)

VS Code version: 1.10.2
C# Extension version: 1.7.0-beta4

Steps to reproduce

1. Open a folder that contains a .csproj file.
2. MSBuild detects the project file and automatically creates obj and bin folders.

Desired behavior

I'd like a setting to disable this behavior. When using VSC to work on documentation samples, I'd like to be able to use VSC/OmniSharp without MSBuild creating obj and bin folders merely because I've opened a folder that contains a .csproj file.

As it stands today, I must stop for a few seconds to delete them each time MSBuild creates them. It's especially troublesome when I open a folder that contains several project files in several subfolders ... I must delete multiple pairs of these folders in each project folder.

[guardrex]

This is still a pain point. Opening a project folder in my local dotnet/docs repo to mod some documentation sample code fires off several dozen (or hundreds ... idk how many) project load attempts. I still need a way to disable this behavior. I'd like to have a setting that I can add to my current ...

"csharp.suppressDotnetInstallWarning": true,
"csharp.suppressDotnetRestoreNotification": true,

... settings that will disable this MSBuild behavior, too. Ideally, VSC/OmniSharp/MSBuild should do nothing when a project folder is opened for working on the docs sample projects. The Intellisense behaviors are great and welcome when working on these files (e.g., C#) ... it's just the behaviors that try to load projects, restore deps, create obj/bin folders, build the project, or anything along those lines that are bothersome.

@DustinCampbell Is there any way you can think of that I can workaround/hack to stop the MSBuild behavior short of actually moving to a different IDE? (I'll suffer this before changing IDE, because VSC/Omnisharp are so great otherwise 😄 👍). Thanks in advance for any tips or ideas.

[pflannery]

@DustinCampbell I now have the invasive problem you feared in my nodejs extension https://github.com/vscode-contrib/vscode-versionlens. This extension analyses csproj files and shows you nuget version information.

I have smoke tests that contain csproj files but I don't need to build the cs project. I only need to see the xml and the codelenses my extension generates. (these smoke tests are essential for my project testing)

I've never had an issue until recently but I now see a list of csharp problems in the vscode window and I also get a warning message when I try to run debug tasks.

is it possible to disable the auto scanning?

[pflannery]

@DustinCampbell just to add, whilst debugging my nodejs extension and stepping through the javascript I get interrupted by:

I then have to step through the csharp to get back to the last line I was debugging

omnisharp ext version is v1.14.0

[DustinCampbell]

@pflannery: Could you file a separate issue for this? What you described does not seem related to the particular issue reported here.

[pflannery]

@DustinCampbell I can just it seemed related because MSBuild is detecting the project file and automatically creates obj and bin folders then reporting all the errors for the file.

[RudraSwat]

I'm facing this issue, as well

[murshex]

Need this too

[oakad]

This has a further implication. Namely, if the build is configured to use external obj and bin directories outside of the tree (a most useful practice) VSCode will plainly break it. It will be impossible to build anything until VSCode is closed or csharp extension disabled and spurious bin/obj dirs deleted.

To this end, I, personally believe it will be most handy if the following could be investigated:

1. Make the location of bin/obj dirs configurable and put them somewhere in VSCode cache by default (-p:BaseIntermediateOutputPath=something -p:BaseOutputPath=something)
2. Make some sort of button to temporarily enable/disable omnisharp without the need to reload the window(s)
3. Alternatively, somehow decouple the omnisharp autobuild from the default dotnet build server instance (by spinning up a dedicated instance or something)

[varnk]

Has this issue been resolved? I am facing a similar problem. If I open a folder that contains C# projects, the extension will run a build in the background and cause an obj folder to be created. This causes a problem if this folder is a Git repo that I am viewing, because suddenly Git will detect the new obj folder and add it to unstaged changes, which causes some confusion because I didn't make any changes, the extension made them. The folder should stay clean when I browse it with VS Code. It shouldn't add files when I don't initiate a compile and just view the folder contents.

[JoeRobich]

@varnk As a workaround, it is recommended that both bin and obj folders be added to your repo's .gitignore file. Roslyn has a very complete .gitignore that you can reference - https://github.com/dotnet/roslyn/blob/2fd58951039e953cbd5a3735c8eb8426d35a4cfe/.gitignore#L18-L19

[JaneySprings]

I use .NET MAUI for mobile development. If I open 'new maui' template, OmniSharp will create incorrect bin\obj folders with which it is impossible to build project with 'dotnet build' (always build error). I have to delete these folders and kill the dotnet process. After that, 'dotnet build' works well

[KostaMadorsky]

This makes VS Code unusable for our repo with 2k+ projects.
VSCode uses 20-50% CPU and uses more and more RAM (11GB and keeps going).

It keeps creating bin/obj folders after you run git clean -dfx

[KostaMadorsky]

If you still need C# rich support for big codebases, setting"omnisharp.enableMsBuildLoadProjectsOnDemand": true seems to do the trick.
It will only start loading projects when a *.cs file is opened.

If you only use VSCode for find/replace, navigation and git, then disabling C# extension for the workspace would work the best.

[JoeRobich]

A design time build is necessary to properly load projects and references and is necessary for this extension.

[oakad]

Nobody argues with the necessity of design builds. The point here is that "obj" and "bin" can be safely moved to a temp directory with a bit of msbuild property messing.