ClickOnce application does not start through Process.Start("x.abc") with *.abc associated to the ClickOnce application

Question

I have successfully developed and deployed a ClickOnce application which registers an associated file extension, for instance *.abc. When I click on a file named x.abc or if I type x.abc from the command prompt, the ClickOnce application starts, and I can retrieve the file through the dedicated API. I can also launch the application programmatically with the following code:

System.Diagnostics.Process.Start ("x.abc");

Everything works fine on my Windows Vista 64 bit box.

However, if I try to do exactly the same thing on a Windows 7 (also 64 bit ), I have a very strange problem. Here is what I observe:

1. Manual start of x.abc by double-clicking it from the Explorer works.
2. Manual start of x.abc from the command prompt works.
3. Process.Start("x.abc") does not start the application; however, the process object returned shows that there was not error and that the ClickOnce application somehow exited immediately. But even a Trace at the very beginning of the ClickOnce application is never reached.
4. Stranger yet, Process.Start("x.bat") with a file x.bat containing the single line x.abc does not start the ClickOnce application either! Same x.bat started from the Explorer works (of course).

Trying to analyse what happens with ProcMon was not very helpful, as the ClickOnce process of launching an application is very difficult to follow, from my point of view. I observe rundll32 getting to work, but no evidence of any failure.

The program which is doing the Process.Start is a full trust console application with really nothing fancy.

I can't see what changed with respect to how ClickOnce applications are handled on Windows 7 and why Process.Start would not do exactly the same as launching the file from Explorer. It's worth to mention that using more advanced versions of the Start method with ProcessStartInfo and setting UseShellExecute to true did not help either.

Starting cmd with Process.Start and then trying to launch x.abc shows exactly the same problem. If I compare the environment settings with a cmd started manually, I see differences in how ProgramFiles is defined (the first one points to C:\Program Files (x86) whereas the second points to C:\Program Files). The applications started from my .NET application are started on the 32-bit emulation layer (SysWoW64).

I was able to reproduce the launch failure of x.abc by starting a 32-bit version of the command prompt (that is, %windir%\SysWoW64\cmd.exe) and then typing x.abc at the prompt. I have also found an ugly workaround, which is to start a 64-bit command prompt from the 32-bit environment by launching %windir%\Sysnative\cmd.exe /C x.abc instead of x.abc.

But I'd rather use a clean way of doing it (or have a Microsoft representative tell me that this is indeed an issue with Windows 7 and/or ClickOncce and that it will be fixed soon).

Answer 1

It looks like you've build your application using 'x32' as the target platform which makes Process.Start spawn a x32-bit process. And as I guess Windows 7 stores file associations for 32-bit and 64-bit applications separately.

If you don't have COM or unmanaged 32-bit dependencies you could try building your application for 'Any' target platform instead of 'x32'.

I investigated some further and found that ClickOnce installer creates the following open verb for any associated file extension (GUID is unique per application):

rundll32.exe dfshim.dll, ShOpenVerbExtension {dce01888-35e8-4df3-af35-cd971f520d8d} %1

Using Process Monitor, I found that the 32-bit version fails to open HKCU\Software\Classes\Wow6432Node\CLSID\{dce01888-35e8-4df3-af35-cd971f520d8d} registry key. (the 64-bit version successfully opens it at HKCU\Software\Classes\CLSID\{dce01888-35e8-4df3-af35-cd971f520d8d}.)

So for me it is indeed a ClickOnce bug. If I were you, I would use that dirty %WinDir%\system32\cmd.exe /C test.abc workaround. (Which appears to work -- tried from x32 Task Manager.)

I've added this issue to the Microsoft Connect (update 2013-02-13: that link is rotten).