Bug description
dotnet-ef fails during project metadata retrieval when --project and --startup-project point to an SDK-style project through a UNC path containing spaces.
The verbose output shows that the original project path begins with the normal UNC prefix (\\FILESERVER\...), but the generated dotnet msbuild invocation receives a path with four leading backslashes inside the quoted argument (\\\\FILESERVER\...).
The same project can be processed by mapping the UNC share to a drive letter first.
Your code
The affected project is an SDK-style .NET project targeting `net10.0`.
The issue can be reproduced with this command:
dotnet tool run dotnet-ef migrations list `
--project "\\FILESERVER\DevShare\Sample Solution\Server\Api Project\Api Project.csproj" `
--startup-project "\\FILESERVER\DevShare\Sample Solution\Server\Api Project\Api Project.csproj" `
--context SampleDbContext `
--framework net10.0 `
--verbose
Anonymized project path:
\\FILESERVER\DevShare\Sample Solution\Server\Api Project\Api Project.csproj
The EF Core CLI is installed as a local tool and invoked through:
dotnet tool run dotnet-ef
Stack traces
Microsoft.EntityFrameworkCore.Tools.CommandException: Unable to retrieve project metadata. Ensure it's an SDK-style project.
at Microsoft.EntityFrameworkCore.Tools.Project.FromFile(String file, String framework, String configuration, String runtime)
at Microsoft.EntityFrameworkCore.Tools.RootCommand.Execute(String[] _)
at Microsoft.EntityFrameworkCore.Tools.Commands.CommandBase.<>c__DisplayClass0_0.<Configure>b__0(String[] args)
at Microsoft.DotNet.Cli.CommandLine.CommandLineApplication.Execute(String[] args)
at Microsoft.EntityFrameworkCore.Tools.Program.Main(String[] args)
Verbose output
Using project '\\FILESERVER\DevShare\Sample Solution\Server\Api Project\Api Project.csproj'.
Using startup project '\\FILESERVER\DevShare\Sample Solution\Server\Api Project\Api Project.csproj'.
dotnet msbuild /property:TargetFramework=net10.0 /getProperty:ProjectName /getProperty:AssemblyName /getProperty:DesignAssembly /getProperty:Language /getProperty:OutputPath /getProperty:PlatformTarget /getProperty:ProjectAssetsFile /getProperty:ProjectDir /getProperty:RootNamespace /getProperty:RuntimeFrameworkVersion /getProperty:TargetFileName /getProperty:TargetFrameworkMoniker /getProperty:Nullable /getProperty:TargetFramework /getProperty:TargetPlatformIdentifier /getProperty:Platform /t:ResolvePackageAssets /getItem:RuntimeCopyLocalItems "\\\\FILESERVER\DevShare\Sample Solution\Server\Api Project\Api Project.csproj"
Microsoft.EntityFrameworkCore.Tools.CommandException: Unable to retrieve project metadata. Ensure it's an SDK-style project.
at Microsoft.EntityFrameworkCore.Tools.Project.FromFile(String file, String framework, String configuration, String runtime)
at Microsoft.EntityFrameworkCore.Tools.RootCommand.Execute(String[] _)
at Microsoft.EntityFrameworkCore.Tools.Commands.CommandBase.<>c__DisplayClass0_0.<Configure>b__0(String[] args)
at Microsoft.DotNet.Cli.CommandLine.CommandLineApplication.Execute(String[] args)
at Microsoft.EntityFrameworkCore.Tools.Program.Main(String[] args)
Unable to retrieve project metadata. Ensure it's an SDK-style project.
EF Core version
10.0.7
Database provider
Microsoft.EntityFrameworkCore.SqlServer
Target framework
.NET 10.0
Operating system
Windows 11
IDE
Not applicable — reproduced using dotnet CLI / dotnet-ef local tool
Bug description
dotnet-effails during project metadata retrieval when--projectand--startup-projectpoint to an SDK-style project through a UNC path containing spaces.The verbose output shows that the original project path begins with the normal UNC prefix (
\\FILESERVER\...), but the generateddotnet msbuildinvocation receives a path with four leading backslashes inside the quoted argument (\\\\FILESERVER\...).The same project can be processed by mapping the UNC share to a drive letter first.
Your code
Stack traces
Verbose output
EF Core version
10.0.7
Database provider
Microsoft.EntityFrameworkCore.SqlServer
Target framework
.NET 10.0
Operating system
Windows 11
IDE
Not applicable — reproduced using dotnet CLI / dotnet-ef local tool