So I’m working on a project that requires that we create a custom URL Protocol so that when users click on a link in the web browser, an agent on their machine opens a file in the appropriate application on their computer from a network share inside of the corporation.
For example, say they click on a link to a PDF in their browser that’s at path \\MyServer\Files\MyPdfFile.pdf. This agent will launch the file using Process.Start(“\\MyServer\Files\MyPdfFile.pdf”) and the OS takes over, Adobe’s products are loaded, and the file is displayed.
The way that the custom url protocol works is that it launches a new instance of the associated agent every time the link is clicked. Having many of these running isn’t desirable, since we’re starting the agent on login, so to handle that, we check to see if another is running, and if it is, we make a call to it using WCF’s net.tcp, pass it the file to open, and then shut down the second instance of the agent, while the first instance opens the file.
Everything worked great until we tried to launch Excel files. For some reason we are unable to determine, and on multiple computers and OS’s, Excel takes up to 30 seconds to launch, even though if you open the file up directly, it opens instantly. We think it’s some kind of security check.
We tried several things, including using a startinfo.UseShellExecute=true setting, and nothing worked. If you made a button in the agent that called the code to launch, it was instant, but if it was the agent calling itself and then trying to launch Excel, it took 30 seconds. Annoying.
To fix it, all we had to do was have the call to launch put on a background thread. Task.Run(() => Launch(filename)) made it work.
Why does changing the thread make a difference? I have no idea.
If you run into this, though, at least you’ll know the quick way to make it behave.