EDN Admin
Well-known member
Hi folks,
I have a COM dll built with VS ATL for a Windows XP thumbnail extractor
shell extension that self-registers OK with regsvr32. The same dll will
also install OK using a Visual Studio Setup & Deploymnet project .msi when
the file is manually added to the "SelfReg" table in the .msi using Orca.
(Havent tried the vsdrpCOMSelfReg Register property setting yet.)
Were trying to follow "the rules" about not using self-registration, but at
the same time, wed prefer not to have to hardcode stuff in the .msi
Registry table or the Setup and Deployment project Registry editor.
However, Im running into a problem with the "Register" property "vsdrpCOM"
and "vsdrfCOM" settings in Setup and Deployment Projects with this dll.
If I create the setup in the same solution with the dll project and use the
"Primary Outputs" of the dll build project, I get the "vsdrpCOM..." options.
If I set it to vsdrpCOM and check the .msi after the setup build, none of
the COM registry settings were added to the "Registry" table. The same
thing happens if I create a standalone setup referencing only the dll itself
and use the "vsdrfCOM" setting -- no registry entries.
I think my overall VS setup is OK -- these settings seem to work with a
third-party sample COM server dll created expressly to demonstrate the
vsdr-COM setting. In that case, the registry entries are added to the
Registry table in the .msi.
FWIW, the "OLESelfRegister" version string property is present in the .rc
version resource.
There are some relatively unsual things about the dll from the standpoint of
the stuff the ATL wizards generate, and I wonder if thats the cause of the
problem. In particular, based on the recommendation of one of the few shell
extension articles Ive been able to find, I removed the type library
generation and registration items from the project, I also removed the
proxy-stub sub-project because the shell "owns" the interfaces in this case.
(I did set the type library registration option settings to "false" in the
DLLRegisterServer/DLLUnRegisterServer functions.)
Another thing thats a bit different is that I added entries to the .rgs
files generated by the wizards to cause the thumbnail "ShellEx" entries to
be added under the file extensions key, as well as the entries necessary to
have the Windows Event Log use the dll for the message strings resources
used in events we send to the Event Log. I also added a couple of global
substitution strings to the .rgs files so we could use some output from the
message compiler generated .h file for the event string registration.
Does anyone know what aspect of the dll might allow it to work with
regsvr32, but not work with the vsdrpCOM setting? Again, the dll installs
OK when I use regsvr32 or enter it via the "SelfReg" msi table.
Thanks.
View the full article
I have a COM dll built with VS ATL for a Windows XP thumbnail extractor
shell extension that self-registers OK with regsvr32. The same dll will
also install OK using a Visual Studio Setup & Deploymnet project .msi when
the file is manually added to the "SelfReg" table in the .msi using Orca.
(Havent tried the vsdrpCOMSelfReg Register property setting yet.)
Were trying to follow "the rules" about not using self-registration, but at
the same time, wed prefer not to have to hardcode stuff in the .msi
Registry table or the Setup and Deployment project Registry editor.
However, Im running into a problem with the "Register" property "vsdrpCOM"
and "vsdrfCOM" settings in Setup and Deployment Projects with this dll.
If I create the setup in the same solution with the dll project and use the
"Primary Outputs" of the dll build project, I get the "vsdrpCOM..." options.
If I set it to vsdrpCOM and check the .msi after the setup build, none of
the COM registry settings were added to the "Registry" table. The same
thing happens if I create a standalone setup referencing only the dll itself
and use the "vsdrfCOM" setting -- no registry entries.
I think my overall VS setup is OK -- these settings seem to work with a
third-party sample COM server dll created expressly to demonstrate the
vsdr-COM setting. In that case, the registry entries are added to the
Registry table in the .msi.
FWIW, the "OLESelfRegister" version string property is present in the .rc
version resource.
There are some relatively unsual things about the dll from the standpoint of
the stuff the ATL wizards generate, and I wonder if thats the cause of the
problem. In particular, based on the recommendation of one of the few shell
extension articles Ive been able to find, I removed the type library
generation and registration items from the project, I also removed the
proxy-stub sub-project because the shell "owns" the interfaces in this case.
(I did set the type library registration option settings to "false" in the
DLLRegisterServer/DLLUnRegisterServer functions.)
Another thing thats a bit different is that I added entries to the .rgs
files generated by the wizards to cause the thumbnail "ShellEx" entries to
be added under the file extensions key, as well as the entries necessary to
have the Windows Event Log use the dll for the message strings resources
used in events we send to the Event Log. I also added a couple of global
substitution strings to the .rgs files so we could use some output from the
message compiler generated .h file for the event string registration.
Does anyone know what aspect of the dll might allow it to work with
regsvr32, but not work with the vsdrpCOM setting? Again, the dll installs
OK when I use regsvr32 or enter it via the "SelfReg" msi table.
Thanks.
View the full article