locked
How to reinvent Windows Explorer's file extension association feature? RRS feed

  • Question

  • I'd like to reinvent that feature in windows explorer where you click on the file name (perhaps with the extension of ".xls") and windows explorer looks that file extension up in a table and determines that the program to run is "c:\Program Files (x86)\Microsoft Office\Office14\EXCEL.EXE".

    How do I write a powershell program to dump this file extension association table where column one contains the file extension and column two contains the name of the executable (like c:\Program Files (x86)\Microsoft Office\Office14\WINWORD.EXE).

    I'd also like to write a second program that will look at the contents of a file when the extension is ".xml" and handle ambiguities? For example, how can I write a powershell program that returns the name of the appropriate executable file (such as c:\Program Files (x86)\Microsoft Office\Office14\EXCEL.EXE) for a file that contains spreadsheet data and returns c:\Program Files (x86)\Microsoft Office\Office14\WINWORD.EXE for an xml file that is a word document stored in XML format?

    Thank you!

    Siegfried


    siegfried heintze

    Wednesday, December 19, 2012 5:52 AM

Answers

  • (cmd /c ftype) -match "excel"

    Function Get-Assoc {
    	param($program)
    	$exe = cmd /c ftype
    	$ext = cmd /c assoc
    	$exe -match $program  | Where {$ext -match $_.split("=")[0]} | 
    		Foreach {New-Object PSObject -Prop @{Ext = ($ext -match $_.split("=")[0]).split("=")[0];Exe = $_.split("=")[1]}}
    }
    
    # Return all assoc ext with exe 
    Get-Assoc
    
    # Return only ext where string contains excel
    Get-Assoc excel

    • Edited by Kazun Wednesday, December 19, 2012 6:23 AM
    • Marked as answer by siegfried_ Wednesday, December 19, 2012 5:50 PM
    Wednesday, December 19, 2012 5:56 AM
  • Also, let me mention a couple of things explicitly that Kazun points you towards with the

    (cmd /c ftype) -match "excel"

    line.

    The associations Windows returns are actually the commands used to open the document, not precisely the executable path. For example, one of the returned items for Winword on my system is

    Word.Document.12="C:\Program Files\Microsoft Office\Office14\WINWORD.EXE" /n "%1"

    If you're trying to perform some flexible file association work, this may actually be an advantage for you, since you'll be substituting the path in for the %1 value, for example.

    As for the XML association, I have no clue about a general formula, but here's something that works from a quick-and-dirty test.

    Files saved from Word 2010 in Word XML format seem to have a node like this in them:

    <?mso-application progid="Word.Document"?>

    You can load a file as an XML document like this:

    [xml](get-content "C:\Users\aka\Desktop\test.xml")

    The intelligent thing to do for Office documents would be to use XML's xpath query syntax to return the value of the mso-application node's progid attribute, but since I've never really gotten that down cleanly, I used the following to get the application identifier:

    (([xml](get-content "C:\Users\aka\Desktop\test.xml"))."mso-application").Split('"')[1]

    This returns the value Word.Document.

    • Marked as answer by siegfried_ Wednesday, December 19, 2012 5:50 PM
    Wednesday, December 19, 2012 7:25 AM
  • And by the way - this may be completely off-base as a guess about the real problem you're trying to solve in the case of XML files, but Microsoft Office typically takes over XML file associations on install, and its XML editor performs redirection for you. Example from Win7x64 running Office 2010 x64:

    PS> cmd /c assoc .xml
    .xml=xmlfile
    PS> cmd /c ftype xmlfile
    xmlfile="C:\Program Files\Common Files\Microsoft Shared\OFFICE14\MSOXMLED.EXE" /verb open "%1"

    • Marked as answer by siegfried_ Wednesday, December 19, 2012 5:50 PM
    Wednesday, December 19, 2012 3:11 PM

All replies

  • (cmd /c ftype) -match "excel"

    Function Get-Assoc {
    	param($program)
    	$exe = cmd /c ftype
    	$ext = cmd /c assoc
    	$exe -match $program  | Where {$ext -match $_.split("=")[0]} | 
    		Foreach {New-Object PSObject -Prop @{Ext = ($ext -match $_.split("=")[0]).split("=")[0];Exe = $_.split("=")[1]}}
    }
    
    # Return all assoc ext with exe 
    Get-Assoc
    
    # Return only ext where string contains excel
    Get-Assoc excel

    • Edited by Kazun Wednesday, December 19, 2012 6:23 AM
    • Marked as answer by siegfried_ Wednesday, December 19, 2012 5:50 PM
    Wednesday, December 19, 2012 5:56 AM
  • Also, let me mention a couple of things explicitly that Kazun points you towards with the

    (cmd /c ftype) -match "excel"

    line.

    The associations Windows returns are actually the commands used to open the document, not precisely the executable path. For example, one of the returned items for Winword on my system is

    Word.Document.12="C:\Program Files\Microsoft Office\Office14\WINWORD.EXE" /n "%1"

    If you're trying to perform some flexible file association work, this may actually be an advantage for you, since you'll be substituting the path in for the %1 value, for example.

    As for the XML association, I have no clue about a general formula, but here's something that works from a quick-and-dirty test.

    Files saved from Word 2010 in Word XML format seem to have a node like this in them:

    <?mso-application progid="Word.Document"?>

    You can load a file as an XML document like this:

    [xml](get-content "C:\Users\aka\Desktop\test.xml")

    The intelligent thing to do for Office documents would be to use XML's xpath query syntax to return the value of the mso-application node's progid attribute, but since I've never really gotten that down cleanly, I used the following to get the application identifier:

    (([xml](get-content "C:\Users\aka\Desktop\test.xml"))."mso-application").Split('"')[1]

    This returns the value Word.Document.

    • Marked as answer by siegfried_ Wednesday, December 19, 2012 5:50 PM
    Wednesday, December 19, 2012 7:25 AM
  • And by the way - this may be completely off-base as a guess about the real problem you're trying to solve in the case of XML files, but Microsoft Office typically takes over XML file associations on install, and its XML editor performs redirection for you. Example from Win7x64 running Office 2010 x64:

    PS> cmd /c assoc .xml
    .xml=xmlfile
    PS> cmd /c ftype xmlfile
    xmlfile="C:\Program Files\Common Files\Microsoft Shared\OFFICE14\MSOXMLED.EXE" /verb open "%1"

    • Marked as answer by siegfried_ Wednesday, December 19, 2012 5:50 PM
    Wednesday, December 19, 2012 3:11 PM