The following line doesn't work:
Process.Start("http://localhost:5000");
Microsoft said that that was the official way to start a new browser, a long time ago, at:
https://support.microsoft.com/en-us/kb/305703
Is there any multiplatform way to do this now? Will it ever be?
There's not a single call that will work on all platforms, but you can use something like this:
public static void OpenBrowser(string url)
{
if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
{
Process.Start(new ProcessStartInfo("cmd", $"/c start {url}"));
}
else if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
{
Process.Start("xdg-open", url);
}
else if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
{
Process.Start("open", url);
}
else
{
...
}
}
I haven't tried the OSX call above, but it seems to do what you want according to a google search. I've used the other two and they work as expected.
Process.Start("https://www.google.com");
does work on Mono though.
I believe the main issue here is that UseShellExecute defaults to true in desktop (and presumably Mono, though I haven't verified), but false in corefx. It's false by default because the APIs necessary to support true on Windows aren't currently available in all target Windows platforms. It can be set to true on Unix. We should revisit this.
cc: @danmosemsft
Slight improvement on what @mellinoe suggested:
if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
{
url = url.Replace("&", "^&");
Process.Start(new ProcessStartInfo("cmd", $"/c start {url}") { CreateNoWindow = true });
}
@gerardog Closing this issue, please reopen if the suggested methods don't work for you.
Why are we closing this? Just because there's a workaround doesn't mean it's addressed. There's functionality that works in desktop and works in mono but doesn't in core: that's something to investigate further. Have we already done so?
Leaving the issue open as a bug for investigation.
FYI - this seemed to work fine on mac for me - El Capitan 10.11.6
This should work now (with useshellexecute=true) on Windows and work on Unix after https://github.com/dotnet/corefx/issues/19956
I'm going to close as it's fixed/covered elsewhere.
ProcessStartInfo psi = new ProcessStartInfo
{
FileName = "cmd",
Arguments = "/c start https://www.baidu.com/s?wd=beijing%20time"
};
Process.Start(psi);
It's worked,thanks.
You should not need to involve cmd.exe. If you set filename to the url and psi.useshellexecute =true it shoukd work. Including on Linux. Can you confirm?
ProcessStartInfo psi = new ProcessStartInfo
{
FileName = url,
UseShellExecute = true
};
Process.Start (psi);
This does work on Windows but not on Linux. In Linux I can simply do:
Process.Start ("xdg-open", url);
which works.
I'm seeing this now on Linux when trying Process.Start("https://www.github.com/")
, and my investigation brought me to this issue:
System.ComponentModel.Win32Exception (0x80004005): Cannot find the specified file
at System.Diagnostics.Process.StartWithShellExecuteEx (System.Diagnostics.ProcessStartInfo startInfo) [0x00102] in <dfe42095fd31410e95d8021f755c3557>:0
at System.Diagnostics.Process.Start () [0x00032] in <dfe42095fd31410e95d8021f755c3557>:0
at (wrapper remoting-invoke-with-check) System.Diagnostics.Process.Start()
at System.Diagnostics.Process.Start (System.Diagnostics.ProcessStartInfo startInfo) [0x0001b] in <dfe42095fd31410e95d8021f755c3557>:0
However, I'm confused because I'm running Mono and this used to work, so I must have installed or upgraded something at some point that exposed me to this (maybe Mono can use corefx libraries?). I've been trying to catch up on the network of related issues and pull requests to assess the impact, but it's a slog. Can anyone please summarize the scope of this issue, i.e. who is and is not affected by it?
If I want my app to work on all of the available platforms and runtimes, do I need to implement a permanent workaround for launching URLs?
Most helpful comment
Why are we closing this? Just because there's a workaround doesn't mean it's addressed. There's functionality that works in desktop and works in mono but doesn't in core: that's something to investigate further. Have we already done so?