What registry keys are responsible for file extension association?

Question

I'm trying to associate file extension to start some type of files with my application. Which registry keys I have to modify to be sure, that when user double click at file it opens with my application.
And how get delete/modify permisions to key "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\<extension>\UserChoice"?
This key created after setting default program by "Open with" dialog.

I've tried:
string ext=".eee";

RegistryKey r = Registry.CurrentUser.OpenSubKey("Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\FileExts\\"+ext);

RegistryPermission f = new
RegistryPermission(RegistryPermissionAccess.Write, r.Name);
f.Assert();
r.OpenSubKey("UserChoice", true); //at this step "Requested registry access is not allowed." exception occured

Answer 1

Extensions are associated in HKEY_CLASSES_ROOT key.

Follow these steps to create a your own association:

1. Open HKEY_CLASSES_ROOT and create a key for extension (if it doesn't exist)
2. Open that key and write into DefaultValue name of your "handler" - somthing like MyApp_ext
3. Close current key and create another key inside HKEY_CLASSES_ROOT with the name of your handler (MyApp_ext)
4. Open that key and write into DefaultValue description of this extension.
5. Create a key DefaultIcon inside the handler key.
6. Open that key and write into DefaultValue full path to the file containing an icon.
7. Close the current key and create \shell\Open\Command keys inside the handler key
8. Open that key and write into DefaultValue full path to your application including parameter.

If you face troubles creating the file extension association, open a regedit and take a look at the structure inside HKEY_CLASSES_ROOT key.

---

Regards,
Danijel

Blog, Twitter

Answer 2

FYI, HKEY_CLASSES_ROOT is a thing of the past.  It comes from Windows 3.1  Starting with Windows 95, new applications should use HKEY_CURRENT_USER\Software\Classes or HKEY_LOCAL_MACHINE\Software\Classes .  If you use the former, you register the file extension just for the logged on user; if you use the latter you register the file extension for all users.  You should get used to do it like this, despite the great amount of information out there that points to HKEY_CLASSES_ROOT .

---

MCP

Answer 3

I am referring to windows 7.

The above works initially, or if there are no other programs associated with the extension. However after using the Windows 7 built-in "Choose default program..." (found under the file-right-click context menu under "Open with") it re-associates the extension with whatever new program you choose.

What happens at this point is that "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\<extension>\UserChoice" is changed by the system, and so the newly selected program takes over.

Running the above code, to regain control over the extension will not work. The only way to regain control, is by either:

• editing the UserChoice -> Progid value, which is not allowed (neither programmatically nor using regedit.exe - access denied).
• Or deleting the UserChoice value and making sure your application is the first in the MRUList value under <extension>\OpenWithList (this can be achieved using regedit.exe but not programmatically)

My question is: Is there a way to achieve this programmatically? What registry values can be changed to regain control of an extension, after is associated with another program?

I know it might seem obvious that if a user through explorer sets the associated application to an extension, that it would be expected to do it the same way again to re-associate the extension to a different application.

The problem however is I have a button in my application that uses the above mentioned code to check for extension association with my application. Unfortunately with the above situation, my application displays a message confirming that the extension is already successfully associated when its not! So is there a way around this?

Answer 4

Stealing file extensions is usually really bad practice. Proper installers will not delete the previous owner - they will add the new app to a choice that the user can pick from a context menu choice.

---

Phil Wilson

Answer 5

This is a mess in Windows 7, I have decided. Between UAC, user-specific associations vs. machine level associations, losing the fine-grained control that we used to have in the control panel, and possible lack of write permission to the registry, users can end up in a catch-22. In addition, the behaviors of a) Windows Explorer, b) ASSOC at the command line, c) ShellExecute, and d) the return value of AssocQueryString can get out of sync. So teemo10, I'm with you on this.

And please don't give us the line about "never override the user's preference." If the system makes it easy for the user to mess up the system, and no way for them to clean it up, we HAVE to have a programmatic way to do it.

I've been working with several users who messed up associations for .PDF, which weren't corrected by installing Adobe Reader 9.3.3, leaving things in an unusable state. (It appears that installing Reader 9.3.4 may have cleared this up, I'm still researching.)

Microsoft needs to document changed behavior in Windows 7 (or was it Vista?).

I'll try to post more specifics when I have them.

Answer 6

The word stealing puts everything out of context. As i stated above, i have a button in my application, which the user freely decides to click on to re-associate a certain set of extensions with my app, in case another app has taken over. At that point, i am simply required to fulfill the user's request. A fake message the displays success (as in my case), or a message that displays failure due to write-access limits put on the administrator/owner of the pc, are both obviously unacceptable outcomes.

Anyway, im still seriously searching for a solution to this problem. Anyone with tips? How do other programmers re-associate extensions to their apps on windows 7, after another app has taken over?

Answer 7

To be able to write to the key UserChoice i needed to take ownership of the key before writing to it. I used code from the following link:

http://www.tomshardware.com/forum/170289-46-programmatically-inheritable-permissions

Specifically the function BOOL setPermissionsExample1().

I was then able to write to the key, and now my file association code works.

 

Answer 8

Hello Webjose

> FYI, HKEY_CLASSES_ROOT is a thing of the past.
> New applications should use HKEY_LOCAL_MACHINE\Software\Classes .

 

This is nonsense!
Both keys are exactly the same!

In the Registry there exist only TWO root keys: HKLM and HKCU.
The other keys (like HKCR) are shortcuts that show a section of the two root keys.

If you don't believe it make the test:
Modify a key in HKEY_LOCAL_MACHINE\Software\Classes and then refresh and then open the corresponding key in HKCR and you will see that it also changed!

Elmü

Answer 9

What is nonsense is your inability to understand that this shortcut was produced by Microsoft in modern OS's in order to support older applications that read or wrote information from HKCR.  This shortcut that has you in awe is Microsoft's backwards compatibility mechanism.  I never said the key was different to the others, did I?  I just said:  Get used to using HKLM\Software\Classes and HKCU\Software\Classes.  First research, then rant, or better yet, don't.

---

MCP

Answer 10

>> FYI, HKEY_CLASSES_ROOT is a thing of the past.
>> New applications should use HKEY_LOCAL_MACHINE\Software\Classes .

>This is nonsense!
>Both keys are exactly the same!

 

Actually, they are not the same -- HKEY_CLASSES_ROOT provides a merged view of HKEY_LOCAL_MACHINE\Software\Classes and HKEY_CURRENT_USER\Software\Classes combined.

Answer 11

Can do the same using group Policy...