Docs: Process.Start changes

[clairernovotny]

Process.Start changed too -- on .NET Framework, UseShellExecute defaulted to true and on .NET Core, it's false.

This means that programs that used Process.Start("https://dot.net"); won't work anymore. They now need a ProcessStartInfo.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: f0f19516-254e-d701-1cd3-d2cf4ddac6e5
• Version Independent ID: dc951b71-083e-6127-99a6-e1278ce8c044
• Content: Breaking changes, .NET Framework to .NET Core 3.0 - .NET Core
• Content Source: docs/core/compatibility/framework-core.md
• Product: dotnet-core
• GitHub Login: @gewarren
• Microsoft Alias: mairaw

[danmosemsft]

This is correct. We did put a note in the API doc here and it should be in the list of breaks between .NET Framework and .NET Core.

Here's the template:

Change in default value of UseShellExecute

UseShellExecute on the ProcessStartInfo class has a default value of false on .NET Core. On .NET Framework, it defaults to true.

Version introduced

.NET Core v2.1. (In earlier versions of .NET Core, UseShellExecute was not implemented for Windows.)

Old behavior

Process.Start(...) allows launching an application directly. In .NET Framework on Windows, Process.Start(...) could also be used to launch an associated application indirectly. For example Process.Start("mytextfile.txt") might launch notepad, and Process.Start("https://microsoft.com") might launch the browser. By passing in a ProcessStartInfo object with UseShellExecute set to false, you can prevent this behavior.

New behavior

The default is reversed. By default, associated applications cannot be launched in this way.

Reason for change

Typically Process.Start(..) is used to explicitly launch an application, which does not need to involve the Windows shell and the associated performance cost. This change makes the default case faster, and allows code to opt-in to the slower path if it needs it.

Recommended action

If you rely on the old behavior, change your Process.Start(..) call to pass a ProcessStartInfo object with UseShellExecute set to true.

Category

CoreFX

Affected APIs

Process.Start
ProcessStartInfo

---

Issue metadata

• Issue type: breaking-change

[mairaw]

We typically cover these sort of changes in the API docs. I think we should move this to the dotnet-api-docs repo since the breaking change doc was done specifically to cover some Winforms scenarios (you can see see it has already been moved and modified to make that more clear). @danmosemsft do you think we should add more info to the API docs regarding this?

[danmosemsft]

@PriyaPurkayastha can you advise? This should be in the API docs linked above, yes, but it should also be in some grand "breaking changes from .NET Framework" topic and @PriyaPurkayastha was figuring out which that topic is.

This breaking change has come up numerous times so it should certainly be in such a centralized topic.

[PriyaPurkayastha]

I am working on a strategy to document .NET Framework->.NET Core breaking changes. There will be three aspects - finding existing documentation for APIs throwing PNSE(or generating a new list if the old list is no longer available), adding link to .NET Framework tech not available in .NET Core and adding new breaking changes(such as this Process.Start one) for newly created GitHub issues that are not covered by the earlier two existing docs. @mairaw I have chatted with @gewarren about this last week and told her that we will sync up again sometime this week or early next week. I will make sure to include you in that discussion. The .NET Framework to .NET Core 1.x/2.x was not on my radar until now, but with the new issues cropping up we might need to tweak the doc structure to accommodate these breaking changes.

[mairaw]

Sounds good @PriyaPurkayastha. As long as I know what's the plan, I'm good.