相关疑难解决方法(0)

例如,我已经成功开发并部署了ClickOnce应用程序,该应用程序注册了相关的文件扩展名*.abc.当我单击命名文件x.abc或x.abc从命令提示符处键入时,ClickOnce应用程序启动,我可以通过专用API检索文件.我还可以使用以下代码以编程方式启动应用程序:

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

我的Windows Vista 64位盒上的一切正常.

但是,如果我尝试在Windows 7(也是64位)上做同样的事情,我有一个非常奇怪的问题.这是我观察到的:

1. x.abc从资源管理器中双击手动启动.
2. x.abc从命令提示符手动启动工作.
3. Process.Start("x.abc")没有启动申请; 但是,返回的进程对象显示没有错误,并且ClickOnce应用程序以某种方式立即退出.但即使是Trace在ClickOnce应用程序的最开始,也永远不会到达.
4. 更奇怪的是,包含单行Process.Start("x.bat")的文件也无法启动ClickOnce应用程序!同样从Explorer工作开始(当然).x.batx.abcx.bat

试图分析发生的事情ProcMon并不是很有帮助,因为从我的观点来看,启动应用程序的ClickOnce过程非常难以遵循.我观察rundll32到上班,但没有任何失败的证据.

正在执行的程序Process.Start是一个完全信任的控制台应用程序,真的没什么特别的.

我无法看到在Windows 7上处理ClickOnce应用程序的方式发生了哪些变化,为什么Process.Start与从Explorer中启动文件完全相同.值得一提的是,使用该Start方法的更高级版本ProcessStartInfo并设置UseShellExecute为true无效.

开始cmd使用Process.Start,然后尝试推出x.abc正好显示了同样的问题.如果我将环境设置与cmd手动启动进行比较,我会看到如何ProgramFiles定义的差异(第一个指向C:\Program Files (x86)而第二个指向C:\Program Files).从我的.NET应用程序启动的应用程序是在32位仿真层(SysWoW64)上启动的.

我能够x.abc通过启动32位版本的命令提示符(即,%windir%\SysWoW64\cmd.exe)然后x.abc在提示符下键入来重现启动失败.我还发现了一个丑陋的解决方法,即通过启动%windir%\Sysnative\cmd.exe /C x.abc而不是从32位环境启动64位命令提示符x.abc. …