Multiple solution file confusion issue

[kfrancis]

Trying to figure out why using dotnet ef suddenly stopped working in our builds, it looks like the dotnet ef command acts differently depending on where you run it.

Steps to reproduce

I was originally trying to debug this on devops, but I can easily see this locally.

• Open a .net dev window to a random path (anything not .net related)
• Run dotnet ef (you should get what you would expect, that you need more arguments)

• Move to the root of a project where there are multiple .sln files
• Run dotnet ef again

Expected: The same thing should happen, the tool should respond asking for more arguments
Actual: The message "Specify which project file to use because this '(whatever your path is)' contains more than one project file" is shown.

Further technical details

EF Core version: I tried this all the way back to 3.1.0 and could see the same issue.
Database provider: n/a
Target framework: .NET Core 3.1.x
Operating system: Microsoft Windows [Version 10.0.18363.959]
IDE: n/a

[pekspro]

I think the problem occurs when where are multiple csproj-files in the same folder. It is easy to reproduce this problem by cloning this repro: https://github.com/pekspro/EfMigrationIssue21655

If I am in the folder C:\EfMigrationIssue21655 and run:

dotnet ef migrations script --project .\NetCore3.1TestApplication\NetCore3.1TestApplication.csproj --context FirstDatabaseContext

it works fine.

But if I am in the folder C:\EfMigrationIssue21655\NetCore3.1TestApplication and run

dotnet ef migrations script --project .\NetCore3.1TestApplication.csproj --context FirstDatabaseContext

I get the error message:

Specify which project file to use because this 'C:\Users\msn\source\repos\EfMigrationIssue21655\NetCore3.1TestApplication' contains more than one project file.

Since the project is specified this is not expected.

[ajcvickers]

/cc @bricelam Heads-up for triage

[bricelam]

We should look at making the help commands a bit lazier--they certainly don't need a project.

The fix for #11330 was supposed to prevent the second command from failing. Maybe it didn't get fixed for this case...

[bricelam]

Oh funny, looks like I said it should throw for this case in the PR (#13294). We should re-discuss.

[kfrancis]

I mean, in this case @bricelam I'm obviously not doing something useful - just intentionally trying to get the help. I'm only doing it this way to simply show the issue, but I'm getting failing builds when running the following from the default working directory:

dotnet ef migrations script --project "$(Build.SourcesDirectory)\src\PatientManagement.EntityFrameworkCore\PatientManagement.EntityFrameworkCore.csproj" --startup-project "$(Build.SourcesDirectory)\src\PatientManagement.Web.Mvc\PatientManagement.Web.Mvc.csproj" --idempotent --verbose --no-build --configuration $(BuildConfiguration) --context "PatientManagementDbContext" --output $(build.artifactstagingdirectory)/migrations/PatientManagementDbContext.sql

All this suddenly started failing on July 10th. I can mitigate it by setting the working directory to be something that doesn't break here, but it didn't make much sense that it fails in this specific case since I'm not working with projects in the local directory but I'm specifying project paths directly.

[ajcvickers]

Splitting off the help part into #21771.

@kfrancis This is the behavior:

• If there is a single project in the current directory, then it will be used as the startup project
• If there are no projects in the current directory, then the specified project will also be used as the startup project
• If there are multiple projects in the current directory, then we throw this exception.

Putting this on the backlog to generate a clearer message/better logging in this case.

[Rick-Anderson]

Update https://stackoverflow.com/questions/49342893 when this is fixed. That's the first hit when searching for this error.

[daerogami]

Just ran into this on our pipeline after upgrading to .NET 5.0
Used to work just fine on .NET Core 3.1
It's like it's completely ignoring the specified parameters in Azure Pipeline Agent, works just fine in a powershell session on the same exact machine for the same repo using the same working directory (relative to the ef project).
Here's the logs from our pipeline if it helps:

##[debug]C:\agent\_work\_tool\dotnet\dotnet.exe arg: migrations script -i -p C:\agent\_work\5\s\src\MyProject.EntityFrameworkCore\MyProject.EntityFrameworkCore.csproj -s C:\agent\_work\5\s\src\MyProject.Web.Host\MyProject.Web.Host.csproj -o C:\agent\_work\5\a\Migrations\migration.sql
##[debug]exec tool: C:\agent\_work\_tool\dotnet\dotnet.exe
##[debug]arguments:
##[debug]   ef
##[debug]   migrations
##[debug]   script
##[debug]   -i
##[debug]   -p
##[debug]   C:\agent\_work\5\s\src\MyProject.EntityFrameworkCore\MyProject.EntityFrameworkCore.csproj
##[debug]   -s
##[debug]   C:\agent\_work\5\s\src\MyProject.Web.Host\MyProject.Web.Host.csproj
##[debug]   -o
##[debug]   C:\agent\_work\5\a\Migrations\migration.sql
C:\agent\_work\_tool\dotnet\dotnet.exe ef migrations script -i -p C:\agent\_work\5\s\src\MyProject.EntityFrameworkCore\MyProject.EntityFrameworkCore.csproj -s C:\agent\_work\5\s\src\MyProject.Web.Host\MyProject.Web.Host.csproj -o C:\agent\_work\5\a\Migrations\migration.sql
Specify which project file to use because this 'C:\agent\_work\5\s' contains more than one project file.
##[debug]Exit code 1 received from tool 'C:\agent\_work\_tool\dotnet\dotnet.exe'
##[debug]STDIO streams have closed for tool 'C:\agent\_work\_tool\dotnet\dotnet.exe'
##[error]Error: The process 'C:\agent\_work\_tool\dotnet\dotnet.exe' failed with exit code 1
##[debug]Processed: ##vso[task.issue type=error;]Error: The process 'C:\agent\_work\_tool\dotnet\dotnet.exe' failed with exit code 1
Info: Azure Pipelines hosted agents have been updated and now contain .Net 5.x SDK/Runtime along with the older .Net Core version which are currently lts. Unless you have locked down a SDK version for your project(s), 5.x SDK might be picked up which might have breaking behavior as compared to previous versions. You can learn more about the breaking changes here: https://docs.microsoft.com/en-us/dotnet/core/tools/ and https://docs.microsoft.com/en-us/dotnet/core/compatibility/ . To learn about more such changes and troubleshoot, refer here: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#troubleshooting
##[debug]task result: Failed
##[error]Dotnet command failed with non-zero exit code on the following projects : 
##[debug]Processed: ##vso[task.issue type=error;]Dotnet command failed with non-zero exit code on the following projects : 
##[debug]Processed: ##vso[task.complete result=Failed;]Dotnet command failed with non-zero exit code on the following projects : 

Edit: I added -v and didn't get any extra output.

[Tylerflx]

Seems like using --project would give me a problem so I changed to -p and it started to work

dotnet ef migrations add RemovedEmailColumn -p "React - Backup.csproj" --startup-project "React.csproj" 

Followed this answer Stackoverflow

[tumbledwyer]

How is this still not fixed yet in v7.0.9?
If you have 2 .sln files in your root, it doesn't matter what commands you give, dotnet ef throws the same exception.

[Timka654]

v8.0.5 - too
If current directory have 2 .csproj files and invoke "dotnet ef migrations add" with any combines --project, --startup-project parameters - not have any results

Projects

• Project.Shared.csproj
• Project.Shared.Server.csproj

Project have

• EF PackageReferences

		<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="8.0.5">
			<PrivateAssets>all</PrivateAssets>
			<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
		</PackageReference>
		<PackageReference Include="Npgsql.EntityFrameworkCore.PostgreSQL" Version="8.0.4" />

• "Directory.Build.props" with next content(Unity integrate)

<Project>
	<!-- See https://aka.ms/dotnet/msbuild/customize for more details on customizing your build -->
	<PropertyGroup>
		<BaseIntermediateOutputPath>artifacts~/$(MSBuildProjectName)/obj</BaseIntermediateOutputPath>
    		<BaseOutputPath>artifacts~/$(MSBuildProjectName)/bin</BaseOutputPath>
	</PropertyGroup>
</Project>

how fix - move up to parent directory with "cd .." and add to your command properties "project" and "startup-project", a your new relative path to csproj file
(In my case - parent folder not contains any .sln files)
this can help avoid problem... but need to fix