¿Está asociada una aplicación con una extensión determinada?

Question

A veces es deseable que su aplicación abra la aplicación predeterminada para un archivo. Por ejemplo, para abrir un archivo PDF que puede utilizar:

System.Diagnostics.Process.Start("Filename.pdf"); 

Para abrir una imagen, usted sólo tiene que utilizar el mismo código con un nombre diferente:

System.Diagnostics.Process.Start("Filename.gif"); 

Algunas extensiones (.gif por ejemplo) casi siempre tiene un controlador predeterminado, incluso en una instalación base de Windows. Sin embargo, algunas extensiones (.pdf por ejemplo) a menudo no tienen una aplicación instalada para manejarlas.

En estos casos, sería deseable determinar si una aplicación está asociada con la extensión del archivo que desea abrir antes de realizar la llamada a Process.Start (fileName).

Me pregunto cómo se puede aplicar mejor algo como esto:

static bool ApplicationAssociated(string extension) 
{ 
    var extensionHasAssociatedApplication = false; 

    var condition = // Determine if there is an application installed that is associated with the provided file extension.; 
    if (condition) 
    { 
     extensionHasAssociatedApplication = true; 
    } 

    return extensionHasAssociatedApplication; 
} 

Answer 1

Yo recomendaría siguiendo el consejo de David's answer pero ya que se necesita para detectar una asociación:

Para comprobar si un archivo tiene una asociación puede utilizar la función nativa FindExecutable que es básicamente lo que el Explorador de Windows utiliza internamente ... da un buen código de error (SE_ERR_NOASSOC) si no hay asociación. Tras el éxito, da una ruta al ejecutable respectivo.

Ti DllImport porque es

[DllImport("shell32.dll")] 
static extern int FindExecutable(string lpFile, string lpDirectory, [Out] StringBuilder lpResult); 

Otra opción sería caminar el registro, por ejemplo (no se recomienda ya complejo debido a varios aspets como WoW64 etc.):

La asociación real se almacena en la clave a la que apunta HKEY_CLASSES_ROOT\.pdf - en mi caso AcroExch.Document, por lo que comprobamos HKEY_CLASSES_ROOT\AcroExch.Document. Allí se puede ver (y modificar) el comando que va a ser utilizado para poner en marcha ese tipo de archivo:

HKEY_CLASSES_ROOT\AcroExch.Document\shell\open\command 

Answer 2

En una situación como esta el mejor enfoque es tratar de abrir el documento y detectar el fallo. Tratar de predecir si una asociación de archivos está implementada solo lo lleva a reimplementar las API de ejecución de shell. ¡Es muy difícil hacerlo exactamente correcto y más bien innecesario ya que ya existen!

Answer 3

También deberá consultar el registro para obtener esa información.

que puede seguir a partir de:

HKEY_CLASSES_ROOT\.extension 

y por lo general conduce a algo así como HKEY_CLASSES_ROOT\extfile\Shell\Open\Command

y se llega al comando para abrir el tipo de archivo.

Dependiendo de lo que está haciendo, puede ser ideal para pedir sólo para el perdón (es decir, basta con abrir el archivo y ver)

Answer 4

Toda esa información vive en el registro .. usted podría desplazarse a HKEY_CLASSES_ROOT , encuentre la extensión y vaya desde allí para encontrar el controlador predeterminado. Pero dependiendo del tipo de archivo y de los manejadores asociados, necesitarás entrar en los CLSID y otras cosas ... en su lugar, es mejor que detectes una excepción.

Answer 5

Esta información se encuentra en el registro. Por ejemplo:

# Mount the HKCR drive in powershell 
ps c:\> new-psdrive hkcr registry hkey_classes_root 
ps c:\> cd hkcr:\.cs 

# get default key for .cs 
PS hkcr:\.cs> gp . "" 
(default) : VisualStudio.cs.10.0 
... 

# dereference the "open" verb 
PS hkcr:\.cs> dir ..\VisualStudio.cs.10.0\shell\open 

    Hive: hkey_classes_root\VisualStudio.cs.10.0\shell\open 

Name       Property 
----       -------- 
Command      (default) : "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" /dde 
ddeexec      (default) : Open("%1") 

Answer 6

@Yahia recibe el visto bueno. Estoy publicando mi solución rápida para la posteridad para que pueda ver a qué me refería. Hay muchas mejoras posibles en este código, pero esto le dará la idea:

public static bool HasExecutable(string path) 
{ 
    var executable = FindExecutable(path); 
    return !string.IsNullOrEmpty(executable); 
} 

private static string FindExecutable(string path) 
{ 
    var executable = new StringBuilder(1024); 
    FindExecutable(path, string.Empty, executable); 
    return executable.ToString(); 
} 

[DllImport("shell32.dll", EntryPoint = "FindExecutable")] 
private static extern long FindExecutable(string lpFile, string lpDirectory, StringBuilder lpResult);