File Association with Extension, ProgId and Verb tables.
Dennis Bareis
Up until now I've been using registry to do all file associations I've
needed as encouraged by the SDK doco (negatively) :-)
Another reason is that it Extension/Progrid/Verb tables appear to be
very brutal during uninstall as it doesn't want to share extenstion
and Program IDs with anyone, however it does have the advantage of
advertising features.
It is clear that the above tables don't replace the need for registry
but I intend to use the tables where possible.
I have some questions which hopefully someone will answer:
Q1. Are those 3 tables all that are required?
Except for a possible Windows Installer bug, it worked for me.
Q2. The "Description" column entry in the "ProgId" table was
ignored by Windows Installer (didn't appear in the
registry/explorer).
Is this a known bug? Any ideas?
Q3. Why is the verb keyed by "Extension" and not "ProgId"?
Can I update existing ProgIds (without needing to know extensions
etc)?
Q4. Is there anyway to have a verb use an existing
installed program (already on filesystem)?
Q5. The doco doesn't say anything about what program is executed
however
my testing seems to show that it is the keypath of the component
identified by the "Extension" table.
This table is keyed by extension and component impying that it is
possible to have multiple programs used for my verbs, however the
"Extension" table is the only table that refers to components...
Assuming I create more "Extension" table entries, how do I
associate
the right component with the right verb?
Q6. Anyone know how to continue to use registry and add advertising to
them? If not sounds like a good feature for a future version to
me...
It would be nice if the doco documented, I'm getting sick of try to
read the 9 lines between every one in the "doco"...
Thanks for any information,
Dennis Bareis [MVP]
Felix Wang
Thanks for posting. Let me try to answer the first 2 of your questions
first.
Q1. Are those 3 tables all that are required?
I think you will need them when you need to use the resiliency and
advertising feature of Windows Installer.
Q2. The "Description" column entry in the "ProgId" table was ignored by
Windows Installer (didn't appear in the registry/explorer).
It is not ignored on my side, with Windows Installer 2.0 (Windows XP SP1)
and Windows Installer 3.0 (XP SP2). Typically the value will be stored
under the following key as the "(Default)" value:
HKEY_CLASSES_ROOT\Project1.Class1
Regards,
Felix Wang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Michael Sanford [MVP]
> Q3. Why is the verb keyed by "Extension" and not "ProgId"?
> Can I update existing ProgIds (without needing to know extensions
> etc)?
Associating a Verb with a ProgId doesn't make sense. A ProgId may be
associated with an extension or not. If it allowed you to associate a Verb
with a ProgId which is not associated with an Extension, then it would be a
net result of nothing, and certainly create even more confusion...
> Q4. Is there anyway to have a verb use an existing
> installed program (already on filesystem)?
Not through the Verb table. You need to use the Registry table directly for
that.
> Q5. The doco doesn't say anything about what program is executed
> however
> my testing seems to show that it is the keypath of the component
> identified by the "Extension" table.
> This table is keyed by extension and component impying that it is
> possible to have multiple programs used for my verbs, however the
> "Extension" table is the only table that refers to components...
> Assuming I create more "Extension" table entries, how do I
> associate
> the right component with the right verb?
You can associate a single extension with more than one component. The
executables need to each support all of the Verbs you define since the same
verbs will show for all of them. This is a limit of the schema in a sense,
but AFAIK, they were thinking of common operations, like "Open", "Print",
etc. In most cases, an application lauched with an unrecognized commandline
tend to just ignore it, but of course that just depends on your app design.
> Q6. Anyone know how to continue to use registry and add advertising to
> them? If not sounds like a good feature for a future version to
> me...
The format for the Darwin Descriptors used in the registry to make this work
is unpublished. I think someone hacked it once before, but IMO, trying to
do what you ask would not be a very good idea.
Dennis Bareis
Wed, 27 Oct 2004 09:16:28 GMT, v-f...@online.microsoft.com (Felix Wang) wrote:
>Q2. The "Description" column entry in the "ProgId" table was ignored by
>Windows Installer (didn't appear in the registry/explorer).
>
>It is not ignored on my side, with Windows Installer 2.0 (Windows XP SP1)
>and Windows Installer 3.0 (XP SP2). Typically the value will be stored
>under the following key as the "(Default)" value:
>
>HKEY_CLASSES_ROOT\Project1.Class1
Thats where it should be yes, but it doesn't happen here in:
Windows Installer 3.0.3790.2180 & WSH 5.6 on Microsoft Windows XP (5.1.2600 Service Pack 2).
This is the contents of the 3 tables::
<$Table "Extension">
#(
<$Row
Extension="AABBTestExtn2"
Component_="TestExtnMacro"
ProgId_="ProgId4.AABBTestExtn2"
MIME_=""
Feature_="ALL.3.080.0101.TESTMSI"
>
#)
<$/Table>
<$Table "ProgId">
#(
<$Row
ProgId="ProgId4.AABBTestExtn2"
ProgId_Parent=""
Class_=""
Description="Test Extension2"
Icon_=""
IconIndex=""
>
#)
<$/Table>
<$Table "Verb">
#(
<$Row
Extension_="AABBTestExtn2"
Verb="Open"
Sequence=""
Command="MsgBox"
Argument='"%1"'
>
#)
<$/Table>
Bye,
Dennis
----------------------------
Dennis Bareis (dba...@KillSpam.labyrinth.net.au)
http://www.labyrinth.net.au/~dbareis/index.htm
Freeware automated MSI creation or updating tool (overnight builds etc):
http://www.labyrinth.net.au/~dbareis/makemsi.htm
----------------------------
Dennis Bareis
On Wed, 27 Oct 2004 06:57:42 -0400, "Michael Sanford [MVP]" <msan...@nospam.com> wrote:
>3, 4, 5 and 6 below...
>
>> Q3. Why is the verb keyed by "Extension" and not "ProgId"?
>> Can I update existing ProgIds (without needing to know extensions
>> etc)?
>
>Associating a Verb with a ProgId doesn't make sense. A ProgId may be
>associated with an extension or not. If it allowed you to associate a Verb
>with a ProgId which is not associated with an Extension, then it would be a
>net result of nothing, and certainly create even more confusion...
Well this is the way it appears to have be originally organised hence progids such as "txtfile"
and "Msi.Package"...
>
>> Q4. Is there anyway to have a verb use an existing
>> installed program (already on filesystem)?
>
>Not through the Verb table. You need to use the Registry table directly for
>that.
Thats what I thought, just wanted a positive answer, thanks.
>> Q5. The doco doesn't say anything about what program is executed
>> however
>> my testing seems to show that it is the keypath of the component
>> identified by the "Extension" table.
>> This table is keyed by extension and component impying that it is
>> possible to have multiple programs used for my verbs, however the
>> "Extension" table is the only table that refers to components...
>> Assuming I create more "Extension" table entries, how do I
>> associate
>> the right component with the right verb?
>
>You can associate a single extension with more than one component. The
>executables need to each support all of the Verbs you define since the same
>verbs will show for all of them. This is a limit of the schema in a sense,
>but AFAIK, they were thinking of common operations, like "Open", "Print",
>etc. In most cases, an application lauched with an unrecognized commandline
>tend to just ignore it, but of course that just depends on your app design.
OK, sounds like its back to the registry for me...
>> Q6. Anyone know how to continue to use registry and add advertising to
>> them? If not sounds like a good feature for a future version to
>> me...
>The format for the Darwin Descriptors used in the registry to make this work
>is unpublished. I think someone hacked it once before, but IMO, trying to
>do what you ask would not be a very good idea.
I know how to handle the descriptors, but there is a lot more too it than that, but
perhaps I'll have a closer look...
Thanks for the answers.
Felix Wang
Is it possible that you create a small sample MSI that have this problem?
With the sample, we can try to reproduce the problem and further
investigate it.
Felix Wang
Anyhow, it is discouraged that we do anything that relies on the
implementation on the descriptors. The undocumented implementation is
subject to change in the future releases.
Dennis Bareis
On Mon, 01 Nov 2004 10:43:48 GMT, v-f...@online.microsoft.com (Felix Wang) wrote:
>Hi,
>
>Anyhow, it is discouraged that we do anything that relies on the
>implementation on the descriptors. The undocumented implementation is
>subject to change in the future releases.
It is seldom a good idea to use undocumented features where there is
another documented way around.
It is also not a good idea for an API to be deficient in areas where there
is a real need as that encourages the use of undocumented methods.
Given the major focus on advertising, self repair etc
(plus Windows Installer and Windows reboot queuing "features" which advertising hides),
it would seem to me a good idea to have some sort of hook/way to indicate that
features should be advertised via file associations without going through the tables
as they only supply a small fraction of the required functionaility.
This could be implemented very simply in Windows Installer
(some possible methods are though feature attributes, a property or via an API+automation).
Although perhaps a "logon" advertising (checked at logon) might be better...
Bye,
Dennis
----------------------------
Dennis Bareis [MVP] (dba...@KillSpam.labyrinth.net.au)
http://www.labyrinth.net.au/~dbareis/index.htm
Freeware MSI creation or updating tool (simple and automated):
http://www.labyrinth.net.au/~dbareis/makemsi.htm
----------------------------
Dennis Bareis
On Mon, 01 Nov 2004 10:41:24 GMT, v-f...@online.microsoft.com (Felix Wang) wrote:
>Is it possible that you create a small sample MSI that have this problem?
>With the sample, we can try to reproduce the problem and further
>investigate it.
I supplied the values for the 3 tables in my previous post.
I will email you the sample I just rebuilt and retested.
It includes a screen capture showing the registry and explorer "views" of the problem.
The sample I just built has also shown up another "MAKECAB.EXE" bug
(its got some file date/time stamps incorrect) which I'm going to
have to look at but that's another issue (there always appears to be "one more")...
Bye,
Dennis
----------------------------
Dennis Bareis
On Tue, 02 Nov 2004 08:52:47 +1100, Dennis Bareis <dba...@KillSpam.labyrinth.net.au> wrote:
>I will email you the sample I just rebuilt and retested.
>It includes a screen capture showing the registry and explorer "views" of the problem.
You email address is invalid so I'm attaching it here...
I've never attached a message to a newsgroup post so here goes nothing...
Dennis Bareis
On Tue, 02 Nov 2004 08:52:47 +1100, Dennis Bareis <dba...@KillSpam.labyrinth.net.au> wrote:
>I will email you the sample I just rebuilt and retested.
>It includes a screen capture showing the registry and explorer "views" of the problem.
You email address is invalid so I'm attaching it here...
I've never attached a message to a newsgroup post so here goes nothing...
>Bye,
Dennis Bareis
>I will email you the sample I just rebuilt and retested.
>It includes a screen capture showing the registry and explorer "views" of the problem.
Your email address is invalid and your newsgroup server doesn't accept "large"
attachements but doesn't tell me what this is so I'm not about to start prunning.
Please tell me where to email it...
Felix Wang
It seems that the file is quite large. I will send you an email on how to
upload it.
Dennis Bareis
>It seems that the file is quite large. I will send you an email on how to
>upload it.
>
123K...
Thanks
Felix Wang
I have sent the email to dbareis at labyrinth dot net dot au. Have you
recieved it?
If the MSI is only 123K, you can also send it to my email account directly:
v-felwa at microsoft dot com.
Dennis Bareis
On Wed, 03 Nov 2004 04:29:56 GMT, v-f...@online.microsoft.com (Felix Wang) wrote:
>I have sent the email to dbareis at labyrinth dot net dot au. Have you
>recieved it?
Not that I can remember, I've checked by blacklist and you didn't get on it,
you are now on my whitelist but maybe my ISP detected it as spam...
>If the MSI is only 123K, you can also send it to my email account directly:
>v-felwa at microsoft dot com.
I have now emailed the file to the email address above.
Bye,
Dennis