Desenvolvi e implementei com sucesso um aplicativo ClickOnce que registra uma extensão de arquivo associada, por exemplo*.abc. Quando clico em um arquivo chamadox.abc ou se eu digitarx.abc no prompt de comando, o aplicativo ClickOnce é iniciado e posso recuperar o arquivo por meio da API dedicada. Também posso iniciar o aplicativo por meio de programação com o seguinte código:

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

Tudo funciona bem na minha caixa de 64 bits do Windows Vista.

No entanto, se eu tentar fazer exatamente a mesma coisa em um Windows 7 (também 64 bits), tenho um problema muito estranho. Aqui está o que eu observo:

Início manual dex.abc clicando duas vezes nos trabalhos do Explorer.Início manual dex.abc a partir do prompt de comando funciona.Process.Start("x.abc") não inicia o aplicativo; no entanto, o objeto de processo retornado mostra que não houve erro e que o aplicativo ClickOnce de alguma forma saiu imediatamente. Mas mesmo umTrace no início do aplicativo ClickOnce nunca é alcançado.Estranho aindaProcess.Start("x.bat") com um arquivox.bat contendo a linha únicax.abc não inicia o aplicativo ClickOnce também! Mesmox.bat iniciado a partir dos trabalhos do Explorer (claro).

Tentando analisar o que acontece comProcMon não foi muito útil, pois o processo ClickOnce de iniciar um aplicativo é muito difícil de seguir, do meu ponto de vista. Eu observorundll32 chegar ao trabalho, mas nenhuma evidência de qualquer falha.

O programa que está fazendo oProcess.Start é um aplicativo de console de confiança total com nada realmente extravagante.

Não consigo ver o que mudou com relação a como os aplicativos ClickOnce são manipulados no Windows 7 e por queProcess.Start não faria exatamente o mesmo que lançar o arquivo do Explorer. Vale a pena mencionar que o uso de versões mais avançadas doStart método comProcessStartInfo e estabelecendoUseShellExecute paratrue também não ajudou.

Iniciandocmd comProcess.Start e depois tentar lançarx.abc mostra exatamente o mesmo problema. Se eu comparar as configurações do ambiente com umcmd iniciado manualmente, vejo diferenças na forma comoProgramFiles é definido (o primeiro aponta paraC:\Program Files (x86) enquanto o segundo aponta paraC:\Program Files). Os aplicativos iniciados pelo meu aplicativo .NET são iniciados na camada de emulação de 32 bits (SysWoW64).

Consegui reproduzir a falha de lançamento dox.abc iniciando uma versão de 32 bits do prompt de comando (ou seja,%windir%\SysWoW64\cmd.exe) e depois digitandox.abc no prompt. Eu também encontrei uma solução feia, que é iniciar um prompt de comando de 64 bits a partir do ambiente de 32 bits, iniciando%windir%\Sysnative\cmd.exe /C x.abc ao invés dex.abc.

Mas eu prefiro usar uma maneira limpa de fazê-lo (ou ter um representante da Microsoft me dizendo que isso é realmente um problema com o Windows 7 e / ou ClickOncce e que será corrigido em breve).