c# - 单击一次的应用程序如何确定其应用程序身份？

Question

我有一个点击一次的应用程序，它已正确签名、正确配置并且可以毫无问题地自行安装。

它设置为脱机运行，但从特定 URL 安装，如果我下载并运行 setup.exe，它会安装更新。

所以，基本上一切正常...除了我无法打印出版本号，或从代码中触发更新。如果我尝试，我会遇到可怕的消息:“未设置应用程序标识。”

2017-01-10 13:43:14.8367 ERROR System.Deployment.Application.InvalidDeploymentException: Application identity is not set.
   at System.Deployment.Application.ApplicationDeployment.get_CurrentDeployment()
   at LibDataAgent.Internal.Services.UpdateService.Deployment() System.Deployment.Application.InvalidDeploymentException: Application identity is not set.
   at System.Deployment.Application.ApplicationDeployment.get_CurrentDeployment()
   at LibDataAgent.Internal.Services.UpdateService.Deployment()

我没有在 Debug模式下运行，也没有使用调试版本。

所以这是我的实际问题:

System.Deployment.Application 中的单击一次代码如何在运行时确定应用程序身份？

因此，围绕此还有很多其他问题，但请不要将其作为重复项关闭，据我所知它不是一个。

这是我不想要回答的事情的列表:

• 如何签署一键申请。
• 如何在构建时设置应用程序标识。
• 如何找到“点击一次”应用程序的安装位置。
• 如何在调试时让点击一次的应用程序工作。
• 如何使用 ApplicationDeployment 检查更新。

非常简单，确切地单击一次应用程序做什么，在运行时让它确定应用程序身份。

帮助!

注意事项

我(迄今为止没有结果)解决这个问题的尝试产生了这些笔记:

我敢肯定这与应用程序的启动方式有关，因为从命令行执行应用程序从未使用过单击一次；但从开始菜单执行相同的应用程序将正确返回 IsNetworkDeployed 为 true。

但是，我无法确定技术差异是什么，或者为什么一个人可以正确检测到安装而另一个人不能。 (或者实际上，为什么这个特定的应用程序不能从开始菜单运行，而其他没有明显区别的应用程序可以)。

我尝试过但没有任何区别的事情包括:

• 应用程序的工作目录。
• 直接或通过 shell 启动应用程序 .exe
• 从新的快捷方式启动应用程序

进入开始菜单的“MyApplication.appref-ms”有某种魔力； appref-ms 只是安装路径的 url:

http://s3-ap-southeast-1.amazonaws.com/blahblah/Dev/MyApplication.application#MyApplication.application, Culture=neutral, PublicKeyToken=fdasdfsafads, processorArchitecture=x86

...这以某种方式 启动了应用程序的“点击一次感知”实例。但是如何呢？

Answer 1

我仍然会很高兴地接受一个答案，它解释了启动应用程序的胆量实际上是如何使用身份设置应用程序上下文的，但是现在，对于后来发现这个问题的其他人来说，这是我最好的尝试:

• ClickOnce 应用程序通过点击安装 url 或使用开始菜单上的 .appref-ms 文件启动，其中包含 url。

• 为下载的文件调用 application/x-ms-application MIME 类型处理程序，启动应用程序的“ClickOnce 感知”实例。

• 在运行时，ApplicationContext.Identity 用于确定 ClickOnce 详细信息，并设置 CurrentDeployment 对象。

• 据任何人所知，直接启动为 ClickOnce 应用程序部署的可执行文件(在 C:\Users\Administrator\AppData\Local\Apps\2.0\b107ee1... 或任何安装文件夹中)将总是将IsNetworkDeployed返回为false，并且将无法 self 更新。

实际上，这意味着:

• 您正在寻找您的 .exe 的安装文件夹和路径？不要打扰。即使您知道它在哪里，它在您运行时也不会有正确的 ApplicationContext。

• 要在您的应用程序启动 Internet Explorer 的安装 URL 处生成一个新的“ClickOnce 感知”实例。您不能将命令行参数传递给它。

例如。

var url = "http://s3-ap-southeast-1.amazonaws.com/blahblah/Dev/MyApplication.application#MyApplication.application, Culture=neutral, PublicKeyToken=fdasdfsafads, processorArchitecture=x86";
var psi = new ProcessStartInfo
{
    FileName = @"iexplore",
    Arguments = $"\"{url}\"",
};
Process.Start(psi);

(如果要查找 URL，请在开始菜单中搜索应用程序的 appref-ms 文件；该 url 包含在其中)

...可执行文件如何以身份启动？

不知道；但这是任何人似乎对它的理解:

(tldr；魔法。可能与如何调用 CreateProcess 以使用 ApplicationContext api 以 DFsvc.exe、DFshim.dll 和 DFdll.dll 的某种组合生成应用程序有关)

(其余信息取自 Ian Picknel 的这篇旧博客文章:http://ianpicknell.blogspot.com.au/2010/03/launching-clickonce-application.html)

Once the deployment manifest has been stored in the Temporary Internet Files folder, Internet Explorer then attempts to establish how it should handle the file with the (assumed and actual) .application extension. It checks the user-specific file types at HKCU\Software\Classes and, if it fails to find an .application sub-key there, checks for machine-specific file types at HKCR. Via this means it establishes that the .application extension denotes an Application.Manifest file. It then uses this information to check the user-specific HKCU\Software\Classes\Application.Manifest and machine-specific HKCR\Application.Manifest keys to establish the CLSID of a library which handles Application.Manifest files and yields the result {98af66e4-aa41-4226-b80f-0b1a8f34eeb4}. Finally, it looks up this CLSID in the user-specific HKCU\Software\Classes\CLSID{98af66e4-aa41-4226-b80f-0b1a8f34eeb4} and machine-specific HKCR\CLSID{98af66e4-aa41-4226-b80f-0b1a8f34eeb4} paths to establish that .application files are handled by C:\WINDOWS\system32\DFshim.dll.

This is where things start to get a little complicated. I said earlier that no 'magic' was happening behind the scenes. Well, whilst that was true for the process of retrieving the deployment manifest it most certainly is not true of the process of actually launching the ClickOnce application once the deployment manifest has been retrieved and the handler, DFshim.dll, has been identified.

DFshim.dll is described in the registry as the 'Manifest mime handler' although its file properties describe it as the 'Application Deployment Support Library'. It implements the Internet Explorer MIME handler COM interface. It is a native 32-bit DLL, written in Microsoft Visual C++ 2005, and was installed into C:\Windows\system32 when the .NET Framework 2.0 was installed.

DFshim.dll has a hard-coded reference to DFdll.dll, which it locates by checking the values of HKLM\SOFTWARE\Microsoft.NETFramework\InstallRoot (typically C:\Windows\Microsoft.NET\Framework) and the keys beneath HKLM\SOFTWARE\Microsoft.NETFramework\Policy\AppPatch (typically v2.0.50727, even if a later version of the Framework is installed). DFdll.dll too is a native 32-bit DLL written in Microsoft Visual C++ 2005.

DFdll.dll uses COM services exposed by DFsvc.exe, which is also located in the .NET Framework folder. DFsvc.exe is a standard .NET MSIL assembly. DFsvc contains a single Main method (within the System.Deployment.Application namespace) which simply calls the internal System.Deployment.Application.DFServiceEntryPoint.Initialize method within System.Deployment.dll. The Initialize method registers System.Deployment.Application.DeploymentServiceCom with COM via System.Runtime.InteropServices.RegistrationServices (i.e. it performs the equivalent of CoRegisterClassObject in COM) using the CLSID {33246f92-d56f-4e34-837a-9a49bfc91df3}. This is the means by which its services are made available to DFdll.dll.

The COM service exposed by System.Deployment.Application.DeploymentServiceCom delegates the majority of its methods to other non-ComVisible classes within the System.Deployment.Application namespace. For example, the public ActivateDeployment method calls ActivateDeployment on a new System.Deployment.Application.ApplicationActivator instance, the public CheckForDeploymentUpdate method calls CheckForDeploymentUpdate on System.Deployment.Application.SubscriptionStore, etc.

It is clear that the vast majority of the work surrounding the actual installation and launch of the ClickOnce application is undertaken by classes within the System.Deployment namespace, hosted within DFsvc.exe. DFshim.dll and DFdll.dll appear to primarily be responsible for arbitrating between the COM-based world of Internet Explorer and the .NET-based world of ClickOnce.