microsoft / vscode-dotnettools

This is a feedback repository to capture issues logged for the C# Dev Kit and related extensions from Visual Studio Code
Other
228 stars 12 forks source link

[SUGGESTION] Option to disable solution integration #395

Open matheus-kirchesch opened 1 year ago

matheus-kirchesch commented 1 year ago

Describe the feature you'd like

An option to disable the solution integration, or at least to disable the automatic creation of the .sln file.

Alternatives considered

At least an option to disable the auto generation of the .sln file.

Environment Information

No response

Sour-Codes commented 1 year ago

This was a sudden switch from Omnisharp for me. Having to constantly delete *.sln files is a pain. Immediately tried to find this option, but it doesn't exist.

I guess I could do my own research, but any tl;dr as to why there's always this push to have sln files?

I'm the kind of person to quickly create a related project by copy/pasting an existing project, updating references, and type in the project reference. Then it takes me a while to realize that the reason my intellisense isn't working is because of the unexpected *.sln file not referencing what I swiftly did...

I love the fact that without the *.sln file, these tools just assume that I want to reference everything in that directory, which is 99% of the case.

joserubenh commented 1 year ago

This has ruined my workflow, since my automated build enviroment fails because the dotnet build command is too dumb to distinguish between the csproj and sln target.

Sour-Codes commented 1 year ago

I agree, @joserubenh. There's been no time I ever favor having a sln file ever since VS Code came into existence.

Seems like a sln file is created as soon as the tools loads with VS Code.

I sometimes load VS Code with several projects -- code Projects or I might just want to focus on something specific -- code Projects/ProjectA. Now with multiple, unwanted, unsolicited sln files being created, I notice VS code will confuse itself if I then (being tired of deleting sln at this point) try to Add an existing project by updating one sln file while the interface targets another.

😩 Can you just point me to the line of where sln is being generated so I can just fork this and disintegrate that line?

joserubenh commented 1 year ago

I think this actually breaks a lot of rules. First, I don't want ANY file at all to be created automatically by the IDE, VsCode requires you to build the launch and settings file. Why on earth is an extension writing files to my dir?. makes no sense. The level of etitlement and arrogance of the extension is borderline insulting.

I think it should be made very clear as a design feature that no file should be created automatically. It took me some time to discover that pesky sln file was being written.

KyleKolander commented 1 year ago

Agree 100%. Soooo annoying. I mean, if the creators of the extension (or this functionality in VS Code) think it's a good idea to automatically create a solution file, fine... but at least provide an option to disable that behavior. It's literally making VS Code close to unusable for the simple task of just opening a folder, on the off chance that there might be a .csproj file in it.

martincostello commented 1 year ago

This feature turned out to be the root cause of this issue where I couldn't get dotnet/extensions to build in a terminal after opening the repo with Visual Studio Code to make a trivial edit: https://github.com/dotnet/extensions/issues/4488#issuecomment-1747217526

danmoseley commented 1 year ago

ideally the option would be configurable within the repo, eg meaning "this repo doesn't have an uber-solution file, but don't generate one because we don't want all the projects in a sln because some won't build" .. that would fix @martincostello case.

KyleKolander commented 1 year ago

ideally the option would be configurable within the repo, eg meaning "this repo doesn't have an uber-solution file, but don't generate one because we don't want all the projects in a sln because some won't build" .. that would fix @martincostello case.

Possibly, but it wouldn't help with my use case... just opening the project folder.

martincostello commented 1 year ago

As it hasn't been mentioned here previously that I can see, there is a setting to turn this off at the User and Workspace levels:

https://github.com/dotnet/extensions/pull/4509#issuecomment-1748236445

To disable at the workspace level, add this to .vscode/settings.json:

{
  "dotnet.automaticallyCreateSolutionInWorkspace": false
}
tmds commented 11 months ago

With recent .NET versions, there's a trend to reduce the bloat and boiler plate with features like SDK-style projects, top-level statement programs, and Minimal APIs.

This extension creating sln files without notice feels like a step in the opposite direction.

tmds commented 2 months ago

What is particularly annoying about the creation of sln files is that it breaks working with the .NET CLI.

If you run a command in a directory where the extension added a sln file, the SDK no longer knows if it should use the csproj or the sln file for commands like publish/build/test and fails with:

MSBUILD : error MSB1011: Specify which project or solution file to use because this folder contains more than one project or solution file.

cc @baronfel