I'm trying to run a ClickOnce installer and I get this useless error message from Windows 7: "Windows can't open this file".
The file extension is .appref-ms
Has anyone seen this or have any advice?
I had this issue on a client's machine. It appears that the operating system does not know the correct association for the file extension, but in reality .appref-ms is not a normal extension and is not directly associated with any program.
I found the following page eventually:
https://social.msdn.microsoft.com/forums/windows/en-us/9ff7867c-7e57-468c-a632-762a76f66f6d/windows-7-64-bit-unable-to-open-apprefms
This contains some information on restoring potentially damaged registry keys, which can cause this issue. However, in my opinion it gives the wrong advice to associate dfshim.dll with .appref-ms. When I did this, it created an association to that dll in the registry, but upon checking the registry of a working machine, no such association exists. This association also causes .appref-ms files to lose their application specific icons, and display instead this icon:
In addition, this association did not actually launch my application successfully, but for some others it may actually work (I don't know).
The correct solution is to restore even more registry keys, which cascade to allow windows to treat .appref-ms files more like applications than files to be opened with programs. The necessary keys are below (I may have overzealously included a couple that are not strictly necessary, but at least some of them are):
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.appref-ms]
#="Application.Reference"
[HKEY_CLASSES_ROOT\.application]
"Content Type"="application/x-ms-application"
#="Application.Manifest"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Application.Reference\shell]
#="open"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Application.Reference\shell\open]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Application.Reference\shell\open\command]
#="\"C:\\Windows\\System32\\rundll32.exe\" \"C:\\Windows\\System32\\dfshim.dll\",ShOpenVerbShortcut %1|%2"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Application.Manifest\shell]
#="open"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Application.Manifest\shell\open]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Application.Manifest\shell\open\command]
#="\"C:\\Windows\\System32\\rundll32.exe\" \"C:\\Windows\\System32\\dfshim.dll\",ShOpenVerbApplication %1"
This appears to apply to both .application and .appref-ms type files. The first key identifies .appref-ms as class "Application.Reference". The later key under "Classes\Application.Reference" defines how these types are launched. These are not simple "open with" associations that Windows is trying to help you create (and which will be created under HKCU instead of HKLM).
Related
I created an MSI installer project in VS2015, set up everything, then added a file extension associtation with the "File Types Editor", assigned my extension to my application, as an Open command.
The COMMAND was the application from the "application folder", the EXTENSION was set, then the &OPEN was set as NAME=&Open, Arguments="%1" VERB=open. Nothing else.
I generated the .msi file, then started. At the end of the installation, I found out that in the registry Computer\HKEY_CLASSES_ROOT\\shell\open\command key there were two item, one is (Default) REG_SZ with value "myexe" "%1" as I expected
Unfortunately there was another item: "command", "REG_MULTI_SZ" and the Data was something weird, for example "LZ*a!t4(v=++Tt$)tOk_>[1jfrS!,nB`L6ciHLW!, "%1"" which I don't know what it is. When I delete the .msi file, and double click on a file with my registered extension, a popup dialog appears as "network resource cannot be found" and Windows wants my .msi installer back (browse dialog comes in)! I don't know how to prevent this unwanted situation. :( Any help would be highly appreciate!
Windows Installer uses so-called Darwin Descriptors to implement resiliency, wherein a corrupted installation can be repaired automatically. Your attempt to delete the .msi rather than to uninstall it acts like a corrupted installation, so the system attempts to fix it. However, since the .msi itself has been removed, it has to ask for help.
The short answer here is to suggest that you not worry about the exact values in the registry key. Since you're using an Extension table instead of a Registry table entry, the registry is an implementation detail; you should prefer to ignore such detail. Instead, if after a successful installation your program launches as expected upon double clicking the associated file, and it stops doing so after properly uninstalling your application, all is well.
I am attempting to update the Windows registry to add an icon for my custom file extension, and I have thus far been unsuccessful. My current version is closest to this stackoverflow question. Unfortunately, my file's icon is still one of the generic built-in Windows icons (see screenshot below).
At this point my best guess is perhaps there is something wrong with my .ICO file. I have shared it here on Dropbox
Here is the full registry update I'm making with regedit. As you can see, I am also associating my file extension with a .bat file for execution. That works great. Also the Type displayed in Windows Explorer is PartQuest Archive which is also great (see above screenshot). Alas, no dice with the last entry for the icon.
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\pqunzip]
#="PartQuest Archive"
[HKEY_CLASSES_ROOT\pqunzip\shell]
[HKEY_CLASSES_ROOT\pqunzip\shell\open]
[HKEY_CLASSES_ROOT\pqunzip\shell\open\command]
#="\"C:\\MentorGraphics\\PartQuestTools\\SDD_HOME\\common\\win32\\scripts\\pqunzip.bat\" \"%1\""
[HKEY_CLASSES_ROOT\.pqz]
#="pqunzip"
[HKEY_CLASSES_ROOT\.pqz\DefaultIcon]
#="\"C:\\MentorGraphics\\PartQuestTools\\SDD_HOME\\common\\win32\\config\\decrypted.ico\""
I have also attempted adding a ,1 to the end of the file name since the .ICO file appears it may have two icons embedded in it. This is did not make a difference.
For good measure, I have been rebooting after each change. I'm not certain if this is necessary.
Any tips from the Windows experts around here will certainly be appreciated!
So I did a little reverse-engineering to figure out the issue based on 7Zip's file associations. It turns out that the DefaultIcon key entry should be a child of the application, not the file name. So in my case I need it associated with pqunzip rather than .pqz:
[HKEY_CLASSES_ROOT\pqunzip\DefaultIcon]
#="\"C:\\MentorGraphics\\PartQuestTools\\SDD_HOME\\common\\win32\\config\\decrypted.ico\""
For maximal clarity, this is the entire contents of my .req file that works as expected:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\pqunzip]
#="PartQuest Archive"
[HKEY_CLASSES_ROOT\pqunzip\shell]
[HKEY_CLASSES_ROOT\pqunzip\shell\open]
[HKEY_CLASSES_ROOT\pqunzip\shell\open\command]
#="\"C:\\MentorGraphics\\PartQuestTools\\SDD_HOME\\common\\win32\\scripts\\pqunzip.bat\" \"%1\""
[HKEY_CLASSES_ROOT\pqunzip\DefaultIcon]
#="\"C:\\MentorGraphics\\PartQuestTools\\SDD_HOME\\common\\win32\\config\\decrypted.ico\""
[HKEY_CLASSES_ROOT\.pqz]
#="pqunzip"
I have my application written in Delphi XE that works with PDF files. Applicaiton is Win32. On start I would like to ensure that there is my item in explorer context menu for PDF files. I would like to be able to specify whether it should be added for active user only or for all users (with UAC I will need to restart with Admin privileges but thats ok).
I started with How to associate a Delphi program with a file type, but only for the current user? and How to add item to windows explorer content menu in delphi? . I tested it with manual registry editing via regedit and it worked fine for "new" extensions. But for .pdf it is more complicated as it will be most probably already present in the registry.
On my PC the .pdf key is referencing AcroExch.Document . But adding shell/something subkey to the AcroExch.Document key is not working because it has CurVer subkey referencing to AcroExch.Document.7. However another PC with another verison of Acrobat had this names a little different. It is no problem for me to follow the CurVer reference but is that a correct approach? And what about situation where no PDF reader is installed, how should I name my keys so Acrobat won't overwrite them when installed?
But more pressing matter is in which root should I put my keys? How to associate a Delphi program with a file type, but only for the current user? is mentioning HKLM (Local Machine) and HKCU (Current user). Its seems rather straightforward but I am unable to set values in HKLM from Delphi. Strangely I can create keys:
var reg:TRegistry;
key := '\Software\Classes\'+keyname+'\shell\'+name+'\command';
reg.CreateKey(key);
but I am getting Access Denied when trying to write the actual value:
reg.OpenKey(key,false);
reg.WriteString('',command);
I am getting the same Access Denied exception even on WinXP, no matter if the applicaiton is running as Admin (Win7), I even tried to set permissions (Everyone full control) for the key via regedit (I can edit the value via regedit without problems). I tried creating the registry with different access modes, all with no luck:
reg := TRegistry.Create(KEY_WRITE or KEY_WOW64_64KEY);
reg := TRegistry.Create(KEY_ALL_ACCESS or KEY_WOW64_64KEY);
reg.Access := KEY_ALL_ACCESS;
reg.Access := KEY_WRITE or KEY_WOW64_64KEY;
reg.Access := KEY_ALL_ACCESS or KEY_WOW64_64KEY;
With HKCU everything works fine.
So I tried writing into HKEY_CLASSES_ROOT and it works and actually puts the keys exactly where I want (into HKLM) if running as Admin. But according to http://msdn.microsoft.com/en-us/library/windows/desktop/ms724475.aspx
The HKEY_CLASSES_ROOT (HKCR) key contains file name extension associations and COM class registration information such as ProgIDs, CLSIDs, and IIDs. It is primarily intended for compatibility with the registry in 16-bit Windows.
I do not like the note about the primary purpose being compatibile with 16-bit Windows. And the actual conditions where the changes will be written is more complicated than I would like.
So basically I have these questions:
What is the advantage of using AcroExch.Document and CurVer instead of pointing directly to AcroExch.Document.7? And what are the "best manners" when adding my keys into this structure? What about the case when the .pdf is not yet associated with anything?
Where should I put my keys and why I am not able to write into HKLM?
Edit:
The problem with Access Denied when writing to HKLM was caused by my error. I did use in previous code openKeyReadOnly and I did not notice that it will swtich the Access property to readonly for all subsequent calls.
To answer your other question, if Adobe is not installed yet then obviously the PDF keys will likely not exist in the Registry yet so you would have to create your own .pdf and ProgID keys so that you can attach your Shell command on it. If Adobe is installed afterwards, it is likely going to wipe out your keys and replace them with its own, so you would have to recreate your Shell command within Adobe's key structure. Your app can query the Registry to check for that condition periodically, such as at startup.
You have asked two separate questions. Since I know the answer to one and not the other, I'm going to answer just one. For future reference, I do recommend that you ask a single question at a time.
Where should I put my keys?
You are correct in discerning that you should not use HKCR. The documentation for HKCR says:
Class registration and file name extension information is stored under
both the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER keys. The
HKEY_LOCAL_MACHINE\Software\Classes key contains default settings that
can apply to all users on the local computer. The
HKEY_CURRENT_USER\Software\Classes key contains settings that apply
only to the interactive user. The HKEY_CLASSES_ROOT key provides a
view of the registry that merges the information from these two
sources. HKEY_CLASSES_ROOT also provides this merged view for
applications designed for previous versions of Windows.
....
If you write keys to a key under HKEY_CLASSES_ROOT, the system stores
the information under HKEY_LOCAL_MACHINE\Software\Classes. If you
write values to a key under HKEY_CLASSES_ROOT, and the key already
exists under HKEY_CURRENT_USER\Software\Classes, the system will store
the information there instead of under
HKEY_LOCAL_MACHINE\Software\Classes.
So, it is reasonable to use HKCR for reading, but for writing you typically need to exert control over whether to write to HKLM or HKCU. And that means that you cannot write to HKCR.
So, write to HKLM\Software\Classes for machine-wide settings, and HKCU\Software\Classes for user-specific settings.
Note that in Windows 7 and later neither of these keys is redirected and so you do not need to worry about using KEY_WOW64_64KEY. However, in Vista and XP64, and the equivalent server editions, these keys are redirected and reflected. Which means that it might be prudent to use KEY_WOW64_64KEY.
I have been trying to add context based right click in windows explorer for a file of extension L5X. I have tried HKEY_CLASSES_ROOT\l5xfile\Shell\convert\command and set the (Default) key value to the program I want to have open the file. (I want it to say "Convert" on the context menu) My first issue seems to be that in .NET (even when running elevated) I cannot change the Default key's value. My other issue is changing that Default key value doesn't do anything to the context menu. I would really prefer a no reboot required solution.
Also, I really need this to work on WinXP all the way up to Win7 (including Server 2003, 2008 and 2008R2). If I need to detect OS and do things differently for different OSes, I will but I'm really stuck here.
PS, I tried the solution found here with no luck.
You need administrator rights to write to HKEY_CLASSES_ROOT, HKEY_CLASSES_ROOT is a merged view of HKEY_LOCAL_MACHINE\SOFTWARE\Classes and HKEY_CURRENT_USER\Software\Classes. If you want to install it for just the current user, write to HKEY_CURRENT_USER\Software\Classes
\l5xfile\Shell\convert\command might not be the correct path, when windows looks for context menu entries for a filetype, it first looks in HKEY_CLASSES_ROOT\.EXT, then uses the default value it finds there: HKEY_CLASSES_ROOT\%defaultvaluefrom.EXT%\Shell\*
XP added a new key HKEY_CLASSES_ROOT\SystemFileAssociations designed for non-primary actions where you don't care about the ProgId/Class (The l5xfile part)
MSDN documents all these registry paths and settings, see: File Types and Verbs and File Associations
Explanation:
I don't remember about Linux and I don't know about OS X, but in Windows you can right-click a file and select a program to open it. But how does the OS know exactly how to make the program open it? Does it keep track of the "Open file" dialogs the program has? Does the developer have to specify a special event handler or something for these cases?
For Windows, the answer is in the registry. If you're comfortable reading the registry, run regedit.exe on your Windows machine.
Under HKEY_CLASSES_ROOT, you will see a key list of all file types, .doc, .txt, etc. Each of these keys contains a key called "OpenWithList" or "OpenWithProgIds". An application may have a registered "ProgId", also found under HKEY_CLASSES_ROOT, and it can register it's ProgId to the file types it wants to handle in OpenWithProgIds. Otherwise it registers itself in OpenWithList.
In response to the comment to the first answer (cos I don't have enough rep to comment):
You're thinking of DDE, which is a near-enough deprecated technology. The Windows shell executes the application with the selected file as the first parameter.
The Windows Explorer remembers your previous "Open With..." choices based on file extension in the following key:
HKCR\.ext\OpenWithList
Next time you right-click the file, it looks there and build a list of programs you have previously used to open a particular file type.
Say it finds a key named "myapp.exe". It then looks up the application here:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\myapp.exe
fetches the info where the application is installed. And it goes here:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\myapp.exe
follows the GUID stored there to find out the display name of the application.
To add to the fun, the primary associated application is in the list as well, also everything in the OpenWithProgIds key and everything in:
HKEY_CLASSES_ROOT\*\OpenWithList
as well as their respective HKEY_CURRENT_USER counterparts.
The resulting list of applications is then made unique, sorted and displayed. On selection the file is started like any other file you click on - i.e.:
C:\path\to\myapp.exe "C:\path\to\the\file.ext"
http://windowsxp.mvps.org/OpenWith.htm
File associations are stored in the Registry in: HKEY_CLASSES_ROOT.
You can manage them graphically by using Windows Explorer: (WinXP)
Click Tools/Options/File Types
Or with the "Default Programs" applet in Control Panel. (Vista)
Just for some nostalgia the rather brilliant Acorn archimedes had a much better system with each file type having a unique type number, with a manufacturer and application code (rather like a MAC address) which was written with the file.
This means you can have different files all called .bak opened by the correct application - unlike the windows case where a new installed app steals the ownership of every exiting file of that type. Autocad is especialy bad for this, registering about 20 file types.
The operating system runs the specified program sending as parameter the path of the file to open.
For example, in C#, if you want to know which file the operating system wants you to open you'll need to do:
class Program
{
static void Main(string[] args)
{
if (args.Length == 1) //The OS wants me to open a file
openSomeFileJustBecauseTheOSWantsIt(args[0]);
}
}