[rc2] Fix dotnet-ef migrations bundle command on Linux

[Copilot]

Fixes #36142

Description
The dotnet ef migrations bundle command was failing on Linux because the path construction logic didn't properly normalize directory separators. MSBuild returned OutputPath containing backslashes (e.g., bin\Debug/net10.0) which, when combined with forward-slash project paths on Linux, resulted in mixed separator paths like /home/user/project/bin\Debug/net10.0/App.deps.json, causing the dotnet exec command to fail with "The specified deps.json [path] does not exist".

Customer impact
Customers using EF Core tools on Linux could not create migration bundles using dotnet ef. The workaround would be to call into the underlying ef.dll manually with the correct path, but this is a poor experience.

How found
7 customer reports

Regression
Yes, from EF 9. Introduced in #34574

Testing
Manually verified by creating a test EF project and successfully executing dotnet-ef migrations bundle on Linux

Risk
Low. The change is a simple path normalization.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[AndriySvyryd]

@copilot As verification, create a simple temporary EF project, then use dotnet exec on the ef.dll with the fix to add a migration for the simple project and then to create a bundle for it. Then execute the bundle. Don't commit any of this.
Rewrite the PR summary using this template:

Fixes #{number}

**Description**
{Issue description}

**Customer impact**
{How does the reported issue affects customer's app? Are there workarounds?}

**How found**
{Was it customer reported or found during verification? How many customers are affected?}

**Regression**
{Is it a regression from a released version? Which one?}

**Testing**
{How the changes were tested}

**Risk**
{Low/Medium/High, argument why}

[artl93]

@AndriySvyryd - Path canonicalization is a tough subject. I'm surprised the fix looks this simple. Have we checked at all with our experts like David C or Jeremy K? This seems like something the Path object should have just taken care of for you.

[AndriySvyryd]

@AndriySvyryd - Path canonicalization is a tough subject. I'm surprised the fix looks this simple. Have we checked at all with our experts like David C or Jeremy K? This seems like something the Path object should have just taken care of for you.

This is a very localized fix, there might be other cases regressed by #34574 that are still not fixed. I haven't dug into why OutputPath contained a backslash in the first place.

@jkoritzinsky @JeremyKuhne @jozkee As I understand Path.Combine will preserve directory separators even if invalid but shouldn't Path.GetFullPath convert them to valid separators or throw on Linux?

[JeremyKuhne]

@AndriySvyryd \ is not a directory separator on Unix and will be left as is. Path.GetFullPath will normalize repeated / and remove segments like .. and .. I'll take a look here and see if I have any other comments.

[JeremyKuhne]

If you need to combine segments you should use Path.Join unless you really need Path.Combine's behavior of checking the rooting on the segments (most cases do not).

MSBuild doesn't really handle paths that have back slashes \ on Unix and it is fair to presume that any back slash in an MSBuild value is a /. That said, it would be better if you could get a resolved path from MSBuild that has the separators already normalized if at all possible as that puts the problem of not being able to open my\file out of your hands. Don't worry too much about it though, as it is kind of generally accepted that Unix paths with reserved NTFS/FAT characters are bad form and out of scope.

If you must persist a path between OSes, the best choice is to use / (Path.AltDirectorySeparator) as that will always work on both. That would include any paths that you have in MSBuild files (targets, etc.).

[AndriySvyryd]

Thanks for the tips @JeremyKuhne

If you need to combine segments you should use Path.Join unless you really need Path.Combine's behavior of checking the rooting on the segments (most cases do not).

Since that's not directly related to the reported issue filed #36754 to avoid introducing extra changes in this PR.

That said, it would be better if you could get a resolved path from MSBuild that has the separators already normalized if at all possible as that puts the problem of not being able to open my\file out of your hands.

Unfortunately, we are quite limited in what we can get from MSBuild, we get the property value using

dotnet msbuild /getProperty:OutputPath

[artl93]

RC2. Thank you for the dilligence!