问题
I want to set up my application to have a file association in Windows (additional complication: the file extension could conflict with some other unrelated application). What is the best way to handle a situation like that? Most likely, a user wouldn't have both, but in the event that they do, what is the best way to proceed?
I've been searching stackoverflow and various other sites online, and have a basic idea of how to do this (I've tried it, and it works), but can not find a definitive reference on how this is best done.
Some references say put entries into the registry in HKEY_CLASSES_ROOT. Some say don't do that, and instead put it into HKEY_LOCAL_MACHINE\Software\Classes.
Does the application also need to be registered under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths or HKEY_CLASSES_ROOT\Applications (and is this even the technically correct location with reference to the discussion about HKEY_CLASSES_ROOT vs HKEY_LOCAL_MACHINE\Software\Classes above)?
I've also seen some pages advise about setting "CurVer" and "OpenWithProgids", but I'm not sure how they would help.
I found that I can just create
HKEY_LOCAL_MACHINE\Software\Classes.aaa (Default) AAAapp
HKEY_LOCAL_MACHINE\Software\Classes\AAAapp (Default) AAAapp DefaultIcon "%mypath%\to\AAAappIcon.ico" shell\open\command "%mypath%\to\AAAapp.exe" "%1"
and it works. I didn't create the App Paths or Applications registry key, so those keys do not appear to affect this. As well, the above appears to have no provision for nicely handling the case where an association for an ".aaa" file extension already exists on the system.
Any guidance is appreciated!
回答1:
Old question -- no answer for 7.5 months -- but the following might help future googlers (like me).
HKEY_CLASSES_ROOT is a combined view of
- HKEY_LOCAL_MACHINE\Software\Classes
- HKEY_CURRENT_USER\Software\Classes.
You're not supposed to write to HKEY_CLASSES_ROOT, just use it read-only. Also, the recommended practice is to write to HKEY_CURRENT_USER\Software\Classes rather than HKEY_LOCAL_MACHINE, unless you really need to set things for all users.
Microsoft's documentation seems rather verbose and scattered, so it's taking me a long time to get settled on exactly what i need to do for my own little app. But still, it may be best to first try the official documentation (unless someone can point us to a place that explains things better), and ask questions later if one can't make sense of it.
The entry point for Microsoft's documentation about this area is "Desktop app technologies" at https://msdn.microsoft.com/library/windows/desktop/bg126469.aspx
For file-type registration, it led me to "Implementing a Custom File Format" at https://msdn.microsoft.com/en-us/library/windows/desktop/ff521657(v=vs.85).aspx
From there go into "File Types and File Associations", and from there the sub-menus cover everything you'll need (and more).
Remember to write to HKCU\Software\Classes. It seems like when HKEY_CLASSES_ROOT (HKCR) is written in the docs, it's often just as a convenient way of referring to (HKCU|HKLM)\Software\Classes.
About "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths" or "HKEY_CLASSES_ROOT\Applications":
The MS docs explain how they relate to the keys you've already used. (I'm still getting my head around it, so can't offer a more straightforward explanation.)
Some places seem to say "App Paths" is preferred, but actually you may need to use both, because "App Paths" really is only about paths, and things like SupportedTypes and FriendlyAppName are only in "HK(LM|CU)\Classes\Applications".
来源：https://stackoverflow.com/questions/31165628/windows-file-associations-done-properly