Open cabal95 opened 1 year ago
we're getting this too, we have two .csproj files in the root directory of the project, one for each platform we're targetting.
dotnet watch --project OurProject.csproj run
Results in:
MSBUILD : error MSB1011: Specify which project or solution file to use because this folder contains more than one project or solution file.
If I delete the other .csproj, it works correctly.
Also, if I explicitly tell the run
command to use the same project, it sort of works, but without hot reload.
dotnet watch --project OurProject.csproj run -- --project OurProject.csproj
This also happens when using VS Code with the C# Dev Kit, which auto generates a .sln file when it can't find one.
If the directory has a .sln
file and a .csproj
file, then running dotnet watch
will fail with the above error.
Example: Assume I have MyApp.csproj
and App.sln
in the same directory, executing the following command
dotnet watch --project .\MyApp.csproj
results in this error:
dotnet watch 🔥 Hot reload enabled. For a list of supported edits, see https://aka.ms/dotnet/hot-reload.
💡 Press "Ctrl + R" to restart.
dotnet watch 🔧 Building...
MSBUILD : error MSB1011: Specify which project or solution file to use because this folder contains more than one project or solution file.
dotnet watch ⏳ Waiting for a file to change before restarting dotnet...
There is no way that I can identify to make dotnet watch
work in this situation except by deleting the .sln
file that the C# Dev Kit auto created.
> dotnet --info
.NET SDK:
Version: 8.0.100-preview.5.23303.2
Commit: 3fe444af72
Runtime Environment:
OS Name: Windows
OS Version: 10.0.22621
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\8.0.100-preview.5.23303.2\
Deleting .sln
file does remove the error and allow the dotnet watch
command to work as expected. However, for me and in general according to this stackoverflow post, deleting the .sln
file will stop the intellisense working which makes development a bit slower.
Preferable to use dotnet run
with intellisense rather than dotnet watch
without intellisense.
Still occurring with latest C# Dev kit.
Has anybody found a workaround to run/watch/build the project without deleting the .sln file or disabling the C# Dev Kit extension for vscode?
EDIT: Make sure you open the folder with the root .SLN file in it. If you open the .csproj folder in vscode
it will create another .SLN file and be buggy again.
I now have my
.sln
committed, and my multiple.csproj
files in separate folders, e.g.
\main-project-ui.sln
\main-project-ui\main-project-ui.csproj
\main-project-ui-tests\main-project-ui-tests.csproj
Then I make sure I'm in the
\main-project-ui\
directory in the terminal when runningdotnet watch run
, and it works - because it doesn't find multiple projects.
I'm having exactly the same issue. Any workaround?
We do have the same error, would be nice if this gets addressed.
@marcpopMSFT would we take a PR for this (to pass through the project path) or is there a design question?
For consistency we should flow the project through, yes. @tmat has some changes incoming to this area that might impact/fix this though. If not we'd happily accept a PR.
For me this issues came up today with single project. The project that I downloaded as part of course had solution (.sln) and project file (.csproj) in the same directory. I confirmed that what @arnard76 mentioned helps to fix that issue and as a consequence it removes intellisense support. With googling I found this post where someone posted the reason on why that is happening for msbuild 17 years before. So changed file structure in below way and everything is working as expected for me.
Moved all things except .sln to child folder
And changed reference to csproj file in the .sln
I know this trick might not be possible for production projects. Just putting here if anybody comes with the same situation while this is being fixed for their single temporary projects without loosing intellisense support and dotnet watch.
Hello @danmoseley issue is still popping up, would you take a PR for this , would like to have a closer look into it ?
I found my auto-generated sln file has different filename than my csproj file. Changing the sln filename the same to csproj solved this MSB1011 error. I'm using DotNet 6 and Azure function version 4.
^ wow 😲. Very strange, but this works. I would have assumed this problem would occur because the .sln
and .csproj
have the same name.
Here's my environment
> dotnet --info
.NET SDK:
Version: 8.0.202
Commit: 25674bb2f4
Workload version: 8.0.200-manifests.8cf8de6d
Runtime Environment:
OS Name: Windows
OS Version: 10.0.22631
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\8.0.202\
This issue started occurring regularly for me, because the C# DevKit VS Code extension auto-generates a .sln
(named after the containing folder) when you open a project that doesn't have one.
I had a similar problem, but with dotnet watch --project {projectName}.csproj run
. In my case problem was with run
part, this command also needs a separate --project {projectName}.csproj
. To provide it, you need to run command like this
dotnet watch --project project.csproj run -- --project project.csproj
From documentation [--] <forwarded arguments>
separates arguments that will be passed to the child command (run
in my case)
Facing the same problem with a solution file auto-generated by the C# Dev Kit, and the solution file and .csproj
file have different names. Providing a separate project argument for the run command doesn't change anything for me. I hope this gets addressed soon!
Facing the same problem with a solution file auto-generated by the C# Dev Kit, and the solution file and
.csproj
file have different names. Providing a separate project argument for the run command doesn't change anything for me. I hope this gets addressed soon!
@nek0d3r What dotnet version do you have? For 8, my solution doesn't work, only for <=7
In my case the project was running in dotnet core and then i have migrated my project into core 8. Is any one working on this?
Nearly a year ... really?
Still not able to watch when specifiying a --project, when if they are some other .csproj files in there.
If you use C# Dev Kit extension for VSCode. It generates [PROJECT].generated.sln
for you.
I renamed it to [PROJECT].sln
and it works well.
PS: I don't want to remvoe the sln file as VSCode IntelliSense will stop working.
I found my auto-generated sln file has different filename than my csproj file. Changing the sln filename the same to csproj solved this MSB1011 error. I'm using DotNet 6 and Azure function version 4.
This worked. Thank you very much
This is happening to me when there is a .saproj file with the same name in the same directory even though I am specifying the full name with the extension. Seems like dotnet disregards the file extension when it parses the project name.
I found my auto-generated sln file has different filename than my csproj file. Changing the sln filename the same to csproj solved this MSB1011 error. I'm using DotNet 6 and Azure function version 4.
worked for me as well, I just deleted the generated word from the solution file name.
Just ran into this issue with a Blazor WebAssembly project, .NET 8 - wanted to have a copy of my project with slightly difference references (referencing a local copy of a component library project, instead of the nuget repository version of it) and no combination of --project parameters would work. No .sln file in this folder, just the two .csproj files. Wild that this has been floating around for so long and still not fixed!
Describe the bug
When a directory contains two .csproj files and you use
dotnet watch --project /page/to/project-a.csproj
the watch command correctly watches for changes related to that project, but when it tries to build we get an error:With the verbose output enabled we can see it execute:
So even though we provide the csproj filename to the dotnet watch command, it doesn't get passed on to the msbuild command.
To Reproduce
dotnet watch -v --project project-a.csproj
Reasons for this setup
We are working on slowly migrating a legacy NET Framework web service to .NET (core). We can't do everything all at once so we are doing it one project at a time, which will take a long time because we have a lot of WebForms code to replace.
Additionally, we currently use the legacy web site pseudo-project not an actual web application. Because of this we can't use the new .csproj format required for .NET and net standard. To that end, we have been creating a second csproj in the directory for each converted project that has the net standard / .NET build. This works fine in Visual Studio 2022. The original csproj is used by the WebSite and the new net standard or .NET project is used by the new server code we are slowly building up.
Exceptions (if any)
Further technical details
dotnet --info