Open matheus-kirchesch opened 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.
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.
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?
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.
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.
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
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.
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.
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
}
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.
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
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