[BUG] C# Dev Kit automatically adds unrequested solution files

[julioct]

Describe the Issue

Opened my VS Code folder, which has a single Web project, and out of nowhere a sln file was added next to my csproj file.

Solution files are an unnecessary Visual Studio artifact that does not need to come to the VS Code world. Notice how its strange contents make have no meaning when opened in VS Code:

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio Version 17
VisualStudioVersion = 17.5.001.0
MinimumVisualStudioVersion = 10.0.40219.1
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "GameStore.Api", "GameStore.Api.csproj", "{09651C7F-EB32-42B0-8E2E-DDBD8F9CD6D1}"
EndProject
Global
    GlobalSection(SolutionConfigurationPlatforms) = preSolution
        Debug|Any CPU = Debug|Any CPU
        Release|Any CPU = Release|Any CPU
    EndGlobalSection
    GlobalSection(ProjectConfigurationPlatforms) = postSolution
        {09651C7F-EB32-42B0-8E2E-DDBD8F9CD6D1}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
        {09651C7F-EB32-42B0-8E2E-DDBD8F9CD6D1}.Debug|Any CPU.Build.0 = Debug|Any CPU
        {09651C7F-EB32-42B0-8E2E-DDBD8F9CD6D1}.Release|Any CPU.ActiveCfg = Release|Any CPU
        {09651C7F-EB32-42B0-8E2E-DDBD8F9CD6D1}.Release|Any CPU.Build.0 = Release|Any CPU
    EndGlobalSection
    GlobalSection(SolutionProperties) = preSolution
        HideSolutionNode = FALSE
    EndGlobalSection
    GlobalSection(ExtensibilityGlobals) = postSolution
        SolutionGuid = {B1700D9D-E90E-491D-94D8-F0294B8E964B}
    EndGlobalSection
EndGlobal

The solution file is likely there to support the solution explorer experience, which should be optional. I have never needed that in VS Code since it's straightforward to manage and build multiple projects there (via Microsoft.Build.Traversal), plus it's nice to stick to a real view of the folder structure as opposed to a virtual one.

Steps To Reproduce

1. Ensure the C# Dev Kit extension is installed
2. Create a new web project via CLI:

   dotnet new web -n helloweb01

3. Open the helloweb01 dir in VS Code
4. A few secs after opening the folder, a new helloweb01.sln was created.

Expected Behavior

No sln file should have been created.

Environment Information

OS: Windows 11 VS Code Version: 1.78.2 Extension Version: 0.1.83

[alexrp]

Same boat here; all my projects use Traversal rather than solution files.

[Pete-Fowler]

I agree. I do not think .sln files should be added automatically.

[ProTip]

To add another datapoint; I have a multi-project solution. Occasionally I open one of the projects individually(ie code .) and it pops an extraneous solution file in the current project which I have to cleanup since it breaks the existing solution.

[sayedihashimi]

C# Dev Kit currently relies on a sln file being on disk. The extension calls into the dotnet commands to support restore/build/run/etc. By using a sln file we can provide a better experience when working with NuGet packages as well as other improvements like build. We have considered if we can support an "in memory" solution file, but that would be a significant investment to get all of our tools to work with that. The dotnet CLI works with different executables so implementing an "in memory" sln file would require changes to several different code bases.

This is different from Visual Studio because VS has deep knowledge of the runtime/framework. That has caused problems for users, for example you do a build in VS and it's different from building on the command line. We are trying to see if we can provide a more consistent experience when using the extension and the command line tools.

I have a couple of questions for those impacted by this.

• How significant is this issue?
• If we are able to place the sln file in a different location, would that be better?
  • Folders that we have considered is the .vscode folder or the Visual Studio Code Workspace storage folder (For Windows I believe this is in AppData and for other platforms I believe it's under the user folder. Would that be an improvement?

[alexrp]

It's unclear to me why the extension is so reliant on a physical solution file existing? OmniSharp has supported this setup (loose project files) for years. What functionality in the new extension would be unable to work?

By using a sln file we can provide a better experience when working with NuGet packages

I think that, broadly, the kind of people who use Traversal projects are also much more disciplined about NuGet package management, and so would likely not be using GUI tools for this anyway. For my part, I manually add PackageReference items to my projects and corresponding PackageVersion items in Directory.Packages.props.

as well as other improvements like build.

Also, to be clear, Traversal projects are compatible with the dotnet CLI just like any other solution/project file.

[sayedihashimi]

@alexrp thanks for the comment.

@Michael-Eng can you expand on why C# Dev Kit needs a sln file on disk as well as why Traversal projects are not used instead?

[alexrp]

By the way, just to be clear on this point, OmniSharp never had explicit support for Traversal projects. That might be a nice feature to have in the future, but is not necessary for feature parity. The important part here is just the ability for the C# Dev Kit to function correctly in a workspace with a number of loose .csproj files, without having to write a physical .sln file.

[josh-hemphill]

• How significant is this issue?

Pretty significant; when I have to onboard new devs to a project without .sln when they are used to using solution files in Visual Studio, it's like pulling teeth to try and keep them from trying to load our projects in Visual Studio when that's not what they're built for; the appearance of the solution file ends up further confusing this issue for them and generates a plethora of complaints about "having to use VS Code" from these kinds of devs when trying to get them onboarded.

• If we are able to place the sln file in a different location, would that be better?

As long as our scripts and tasks don't get confused and pick it up, I don't think it would matter too much.

[julioct]

• How significant is this issue?

It is very annoying. You really don't need the solution file and, if you were to generate something, you might as well just generate a build traversal file, which works just as well with the .NET CLI.

I always add a build.proj file at the root to enable build traversal that looks like this:

<Project Sdk="Microsoft.Build.Traversal/3.1.6">
  <ItemGroup>
    <ProjectReference Include="**\*.*proj" />
  </ItemGroup>
</Project>

Then all you have to do is this to build everything:

dotnet build build.proj

Or just this:

dotnet build

• If we are able to place the sln file in a different location, would that be better?

Anything outside of my repo would not bother me, but it's really not needed, and if you can instead create a build.proj or dirs.proj file with build traversal where today you are placing the sln file, it would actually help me.

[MatisseHack]

• How significant is this issue?

This issue is the most important issue I've encountered with the C# extension so far.

I also use build traversal so adding a solution file to my project is not desired. I have to take special care to avoid inadvertently including changes to .vscode/settings.json whenever I commit. It also breaks my muscle memory for CLI commands like dotnet build because now there's "more than one project or solution file."

And as a side note, in my opinion, extensions should never make changes to my repository without asking first (e.g. by presenting a prompt where I can select which project/solution to use).

• If we are able to place the sln file in a different location, would that be better?

This would be fine as long as it's placed in a temp directory somewhere outside my repository and isn't set in the .vscode/settings.json file.

[jpda]

• How significant is this issue?

It breaks my workflow and requires a lot of extra babysitting. Deleting the sln, or working with a project that has existing sln/multiple sln kills intellisense and syntax highlighting. Especially since it also adds the .vscode/settings.json folder/file - it's just generally quite invasive. This means before I commit I've got to delete a bunch of junk, to where I've had to add .vscode and .sln to .gitignore.

Working with a large team using VS and vscode, with multiple solutions in a large file structure also means cleaning out any auto-generated goop before any commits, which is just extra busy work I didn't have pre-devkit.

What made vscode great is that it wasn't visual studio. Maybe legacy dependencies like sln files should stay in the legacy IDE?

• If we are able to place the sln file in a different location, would that be better?

I am surprised that in 2023 a sln file is still such a large dependency, especially given that vscode and c# ext have worked so well now without them for years. If you must have one, ~/.Trash is where I'd prefer on Mac.

[vitek-karas]

How significant is this issue?

Very. This is currently by far the most annoying issue with the C# Dev Kit I ran into.

First it immediately pollutes the repo with a change - which git tries to track and so on. I work in large repos which do have solution files, but only in some places. There are lot of directories with a .csproj which don't have solution files next to them. I often want to use VS Code as a quite editor, so I just go to a directory and code .. And this "breaks" the repo by adding a file which is typically tracked by git to it.

Second, it breaks command line. In a directory with just a .csproj I can type dotnet build and it knows what to do. But once VS Code adds the solution file there, dotnet build now fails with error saying that it doesn't know what to build since there are multiple files it can build (the solution and the project). This can be worked around by adding the name of the file on the command line, but that's a lot more typing which I didn't need before. Also - if there are any scripts or other stuff which will execute .NET SDK those might break because they expect dotnet build to work.

I do use VS Code as either a full IDE - in which case I want the solution explorer and all the other nice features. But I also use it as a fast editor code . - in which case I want it to be "read-only", it should not modify anything on disk. This feature breaks that.

If we are able to place the sln file in a different location, would that be better?

If it's something the tool needs, that's fine, but it should not pollute my repo with this. .vscode might not be good enough since if I had the project setup to work with VS Code I would have that directory in the git as well. It would solve the second problem with .NET CLI, but it would not solve the first problem of polluting my git.

[villecoder]

• How significant is this issue?

Like others, my main concern is the .sln files polluting the repository as well as confusing others about how to load projects. Our team uses a monorepo to organize around our microservices architecture. So opening a service usually involves running code service from the command line and off you go. But it's often useful to open a subdirectory or a file somewhere else in the repo to check for patterns in solving analogous issues elsewhere in the project. That "how did we do this before" habit creates new .sln files that we have to remember not to check in.

It gets annoying when you're working on a feature branch, go to check in code, and see several unrelated folders pop up. Rather than boosting productivity, installing the extension may potentially harm productivity based on how you choose to navigate and invoke the editor.

• If we are able to place the sln file in a different location, would that be better?

I like the idea of adding the .sln file to the .vscode folder. However, doesn't that have an effect on vscode's ability to detect and offer tasks and workspace settings?

For example, the Peacock extension modifies the editor window color. Would it have problems if the root folder is one color, but a subfolder had a different color? Is that burden on the extension developer or on the IDE at that point?

Interested to see where this lands. To work around this issue, I turned off the option to load solutions automatically. It breaks intellisense. But it prevents me from having to sort out which files to commit.

[michaelstaib]

• If we are able to place the sln file in a different location, would that be better?

I think the issue with this is that you might add new projects. I typically never work with the solution view so adding a new project is just a dotnet new classlib -n WhatEver in combination with a developer reload. But if there is already a solution file create by the devkit will it rescan my projects and add them to that temporary solution file.

Fundamentally, I think when working with VSCode you do not work with the expectations that you have with visual studio or rider. I personally are only working with the file view. If there is a solution file being generated it should be in a temp directory outside of the repository and it should be removed after being finished.

It could be a feature going to the solution view and saving the solution. But opening vscode should not just produce code artefacts.

• How significant is this issue?

For me its the single most annoying thing right now because it disrupts how I could work in the past. Now just looking at code will always produce this new artefact.

[BruceRigg2]

This issue alone caused me to uninstall the extension without any further investigation of its features.
As many others have mentioned VSCode works perfectly well without the meaningless gobblegook that is the .sln file.
I only add an sln file when working with TFS (since the TFS source control plugin was removed from VSCode I use VStudio for source control)

[timheuer]

@sayedihashimi didn't we accommodate this now with the setting? Is that the default new setting now?

[sayedihashimi]

Sorry for the delay in replying back here, this got lost in my github notifications. A while back we added a setting that you can use to configure this in the C# Dev Kit extension settings. To get there in VS Code go to Extensions > C# Dev Kit Settings > Automatically Create Solution in Workspace. See the images below.

If you uncheck this box the .sln file will not be created in the workspace folder. Instead, it will be created in a temp folder.

The default is that this checkbox is checked. There are some advanced scenarios where unchecking that checkbox will result in the projects to not build successfully. These are niche scenarios and shouldn't impact most users.

I am going to close this issue now because I believe that we have addressed this issue. If not, please reopen with more details, or open a new issue.

[julioct]

@sayedihashimi Thank you! Can this be the default behavior at least for existing projects?

[sayedihashimi]

@sayedihashimi Thank you! Can this be the default behavior at least for existing projects?

We are not setting this as the default because there is a small percent of scenarios where this approach does not work. To overcome those issues would require significant investment and would take away from other work that is planned. If we receive a significant amount of feedback that we need to make this the default, then we can consider it.

If you configure this setting globally it should affect all things that you load. You should only have to configure this one time. We are hoping that this support will be good enough, but we are listening for feedback.

[codebrane]

The SLN file created by VSCode now breaks dotnet build. The only way to fix the build is to delete the SLN file.

#3594

[sayedihashimi]

Hello everyone, I just wanted to let you know we are looking to see if we can improve this. Current thought is to create a sln file in the .vscode folder if the workspace doesn't contain one. I will keep you posted when I know more. I just wanted to inform everyone that we are still looking at this feedback and planning on improving this experience.

Please keep the feedback coming!