Requesting help to understand Class and ProgID (advertising info) MSI Tables and Self Heal
Hello,
I’ve been working as a MSI packager in a fairly large business in Norway now for the past four or so years. When I begun I really had no knowledge of MSI packaging at all and was basically introduced to packaging via Wise Package Studio. Although colleagues have taught me quite a lot about the general process of application packaging I’ve pretty much been forced to investigate the fine details on MSI’s my self. By that I mean understanding the actually MSI tables and what they do as the majority of people here simply use the Wise GUI for everything.
Since then I’ve progressed and become far more competent in regards to understanding the actual Windows Installer technology. I shy away from Wise and use nothing but plain table editors (InstEd!) whenever possible. Although I know a fair bit and have been able to package pretty much everything thrown at me without major problems there still appears to be so much I don’t know about when it comes to MSI packaging. The questions I keep conjuring up now days nobody else in my workplace seem to have answers to, or at least cannot explain them in any meaningful manner.
To me understanding is visualisation. If I can’t visualize what a specific table of function within Windows Installer does on the actual operating system where it is being installed then I don’t feel like I have understanding. Therefore I struggle a lot when reading about for instance the Class and ProgID tables; I’m unable to properly visualize what the help documentation describes, that is what it actually means in practice.
Take the Class table Windows Installer reference documentation:
To begin I hardly even know what COM is (Component Object Model), much less what COM server-related information is. Secondly the latter part of the first sentence I always thought referenced to installing a package with msiexec /ju (this was always what constituted as ‘advertising’ in my mind).
Then the second sentence, finally something I can work with and visualize! (Although the use of the word *may generate* kind of throws me off. Some row’s will some won’t all depending on the mood of Windows Installer? Meh…) Registry settings, I can deal and understand Registry settings, its concrete; something my stupid self can visualize.
Now, what the hell are these registry settings that are created and when are they created? Second, what are they used for? I guess I should run a test and see what happens on the system when I install a package with Class/ProgID information.
So, I create my own little test .msi and copy over a .dll and the contents of the Class and ProgID tables for that component from a random application I have packaged (original .msi with .mst). I include the .DLL file and place it under a folder in Program Files and copy over calc.exe to use as an advertised shortcut for my little test. As such:
Alright, let’s try to install this sucker. But first lets browse to the registry location where I would expect to see changes:
Okey, so I’ve installed the dummy application and observe the following change in registry:
I tested with both msiexec /I and msiexec /ju and it appears to generate almost the same settings both times. See the difference here:
http://www.avemil.com/msi/test_i.txt
http://www.avemil.com/msi/test_ju.txt
Now, the application I pulled this Class entry from had this information in BOTH the Class table and the Registry table. Leaving me confused. What’s the point in having these exact settings in both the CLASS and Registry tables? I’d assume that if you had them in CLASS you wouldn’t need them under the Registry table and vice versa?
What are these settings, like really? I understand they are related to Windows Installer resilience (self-heal) but how?
The value “GW-+IGK^CA1e@P[tLS(7>(K0`kxYM?@J(M`5bgC9e†appears like some sort of hash thingy and I’m guessing it was created by Windows Installer. Is this used to identify to Windows Installer what package this registry setting came from? Is it this and only this setting that enables triggering of self-healing?
I observe that if I uninstall and reinstall the “application†the hash code (or whatever it is) remains the same.
If someone could provide me with an example where I could manually mess something up so that it would trigger a self-heal doing any action other than clicking on the advertised shortcut, that would help my level of understanding a bit.
I appreciate your attention despite my mindless ramblings. I better stop now, hopefully I’ll be able to phrase better questions after some input from someone that knows what the hell their doing.
Thank you for reading.
Kind regards,
dreyer
I’ve been working as a MSI packager in a fairly large business in Norway now for the past four or so years. When I begun I really had no knowledge of MSI packaging at all and was basically introduced to packaging via Wise Package Studio. Although colleagues have taught me quite a lot about the general process of application packaging I’ve pretty much been forced to investigate the fine details on MSI’s my self. By that I mean understanding the actually MSI tables and what they do as the majority of people here simply use the Wise GUI for everything.
Since then I’ve progressed and become far more competent in regards to understanding the actual Windows Installer technology. I shy away from Wise and use nothing but plain table editors (InstEd!) whenever possible. Although I know a fair bit and have been able to package pretty much everything thrown at me without major problems there still appears to be so much I don’t know about when it comes to MSI packaging. The questions I keep conjuring up now days nobody else in my workplace seem to have answers to, or at least cannot explain them in any meaningful manner.
To me understanding is visualisation. If I can’t visualize what a specific table of function within Windows Installer does on the actual operating system where it is being installed then I don’t feel like I have understanding. Therefore I struggle a lot when reading about for instance the Class and ProgID tables; I’m unable to properly visualize what the help documentation describes, that is what it actually means in practice.
Take the Class table Windows Installer reference documentation:
The Class table contains COM server-related information that must be generated as a part of the product advertisement. Each row may generate a set of registry keys and values. The associated ProgId information is included in this table.
To begin I hardly even know what COM is (Component Object Model), much less what COM server-related information is. Secondly the latter part of the first sentence I always thought referenced to installing a package with msiexec /ju (this was always what constituted as ‘advertising’ in my mind).
Then the second sentence, finally something I can work with and visualize! (Although the use of the word *may generate* kind of throws me off. Some row’s will some won’t all depending on the mood of Windows Installer? Meh…) Registry settings, I can deal and understand Registry settings, its concrete; something my stupid self can visualize.
Now, what the hell are these registry settings that are created and when are they created? Second, what are they used for? I guess I should run a test and see what happens on the system when I install a package with Class/ProgID information.
So, I create my own little test .msi and copy over a .dll and the contents of the Class and ProgID tables for that component from a random application I have packaged (original .msi with .mst). I include the .DLL file and place it under a folder in Program Files and copy over calc.exe to use as an advertised shortcut for my little test. As such:
Alright, let’s try to install this sucker. But first lets browse to the registry location where I would expect to see changes:
Okey, so I’ve installed the dummy application and observe the following change in registry:
I tested with both msiexec /I and msiexec /ju and it appears to generate almost the same settings both times. See the difference here:
http://www.avemil.com/msi/test_i.txt
http://www.avemil.com/msi/test_ju.txt
Now, the application I pulled this Class entry from had this information in BOTH the Class table and the Registry table. Leaving me confused. What’s the point in having these exact settings in both the CLASS and Registry tables? I’d assume that if you had them in CLASS you wouldn’t need them under the Registry table and vice versa?
What are these settings, like really? I understand they are related to Windows Installer resilience (self-heal) but how?
The value “GW-+IGK^CA1e@P[tLS(7>(K0`kxYM?@J(M`5bgC9e†appears like some sort of hash thingy and I’m guessing it was created by Windows Installer. Is this used to identify to Windows Installer what package this registry setting came from? Is it this and only this setting that enables triggering of self-healing?
I observe that if I uninstall and reinstall the “application†the hash code (or whatever it is) remains the same.
If someone could provide me with an example where I could manually mess something up so that it would trigger a self-heal doing any action other than clicking on the advertised shortcut, that would help my level of understanding a bit.
I appreciate your attention despite my mindless ramblings. I better stop now, hopefully I’ll be able to phrase better questions after some input from someone that knows what the hell their doing.
Thank you for reading.
Kind regards,
dreyer
0 Comments
[ + ] Show comments
Answers (37)
Please log in to answer
Posted by:
pjgeutjens
14 years ago
To begin I hardly even know what COM is (Component Object Model), much less what COM server-related information is.
OK, simply put COM is a framework setup to allow cross-platform availability of objects (as used in Object-Oriented) and interprocess communication. Files like DLL's OCX's and EXE's that are in fact collections of functions that need to be made available systemwide, need to register themselves (their classes, their functions, associated filetypes and applications) in your OS. To do this uniformely COM object principles are used.
I could type a wall of text here but instead am going to refer you to here and here. Some good explanations of the whole CLSID / TypeLib / ProgID etc concept.
The value “GW-+IGK^CA1e@P[tLS(7>(K0`kxYM?@J(M`5bgC9e†appears like some sort of hash thingy and I’m guessing it was created by Windows Installer. Is this used to identify to Windows Installer what package this registry setting came from? Is it this and only this setting that enables triggering of self-healing?
It's exacly that, it's actually an encoded representation of the combination Application-Feature-Component that's associated with the entry. It's a "hook" for Windows Installer to verify installation integrity (self-heal). It's also called a Darwin Descriptor
Thank God it's a slow day at work [:D]
Posted by:
AngelD
14 years ago
Hi dreyer,
The B scenario Ian mentioned will mostly happen when you repackage on a non-clean machine and later try to install on a corporate client missing the dependent DLL that existed on the "dirty" packaging machine ;) This is a common newbie mistake.
Remove away from any kind of self registration for COM-components, either use COM advertising (which you're currently trying to grip) or the Registry table.
"can cause random self-repairs"
Sounds like they are used to packages that hasn't been carefully tested before deployment.
So, to decide if you should take the route of COM advertising or "legacy" registration would depend on
B) ignorant people and/or fully qualified processes
C) sufficient of entry points (advertised shortcuts or file extension associations) that the user have to use for the windows installer resiliency to be able to repair broken applications
D) missing entry points except for COM components that can be advertised
If you want to make sure a repair can occur how ever the user launches the application and there exist COM component then advertise it (NO self-registration) so "extra" entry points will be installed to trigger a potential repair if required.
When it comes to Terminal Service/Citrix environment forget about advertisement, users do not have permission to trigger a self-repair. So in the case of TS/Citrix use the Registry table instead, make sure shadow registry takes care of any HKCU entry or by logon script, the latter for any files in the userprofile. You should also use the DISABLEADVTSHORTCUTS property in case of.
The B scenario Ian mentioned will mostly happen when you repackage on a non-clean machine and later try to install on a corporate client missing the dependent DLL that existed on the "dirty" packaging machine ;) This is a common newbie mistake.
Remove away from any kind of self registration for COM-components, either use COM advertising (which you're currently trying to grip) or the Registry table.
"can cause random self-repairs"
Sounds like they are used to packages that hasn't been carefully tested before deployment.
So, to decide if you should take the route of COM advertising or "legacy" registration would depend on
B) ignorant people and/or fully qualified processes
C) sufficient of entry points (advertised shortcuts or file extension associations) that the user have to use for the windows installer resiliency to be able to repair broken applications
D) missing entry points except for COM components that can be advertised
If you want to make sure a repair can occur how ever the user launches the application and there exist COM component then advertise it (NO self-registration) so "extra" entry points will be installed to trigger a potential repair if required.
When it comes to Terminal Service/Citrix environment forget about advertisement, users do not have permission to trigger a self-repair. So in the case of TS/Citrix use the Registry table instead, make sure shadow registry takes care of any HKCU entry or by logon script, the latter for any files in the userprofile. You should also use the DISABLEADVTSHORTCUTS property in case of.
Posted by:
AngelD
14 years ago
The so called random self-repair for a multi-user computer will mostly occur when setting a file as keypath for a component holding user files.
Lets give an example
Package content:
Component1 -> KeyPath=File1
File1: [ProgramFilesFolder]MyAppName\Main.exe
Shortcut1: MyAdvertisedShortcutForFile1
Component2 -> KeyPath=File2
File2: [AppDataFolder]MyAppName\data.bin
Registry1: HKCU\Software\MyAppName\MyRegEntry="MyRegValue"
When the package is installed the keypath metadata for Component2 is written to the registry which will point under the %APPDATA% directory for the user whom installed the package.
When a user triggers an entrypoint (in this case Shortcut1) windows installer will check for broken components; will look something like: get keypath from metadata registry, verify if it exists or not, if missing notify to perform a repair.
Should a repair occur the keypath metadata will be rewritten to point to the resolved keypath (ComponentPath).
Lets go through a two-user logon application launch scenario:
User1 logon to the computer and launches Shortcut1, as it's the first time the user uses the application a repair will occur (due to this package design), a so called user profile-fix.
The keypath metadata for Component2 will be written to the registry with a value of "C:\Documents and Settings\User1\Application Data\MyAppName\data.bin".
User2 logon and launches the Shortcut1; same user profile-fix will occur as for User1 however, the keypath metadata value for Component2 will now hold "C:\Documents and Settings\User2\Application Data\MyAppName\data.bin".
User1 logon again and starts the application by an entry point (Shortcut1), the windows installer resiliency feature steps in for a "sanity" check.
When Component2 is checked windows installer will once again get the keypath (ComponentPath) from the windows installer metadata present in the registry and verifies if the component is broken (missing or corrupt keypath). The keypath metadata held in the registry currently have a value of "C:\Documents and Settings\User2\Application Data\MyAppName\data.bin". Windows installer tries to access the file located in another user's profilepath (remember, this will happen in the user context whom triggered the repair) which will fail as regular users do not have access to other user's profiles. Failing to access a file due to permission or file isn't present will make no difference for windows installer and therefore thinks the file doesn't exist. Windows installer will now notify that the "package" needs to be repaired as a component was found broken.
Windows installer will now perform a reinstall of the package: on feature or component level depending on where the broken component and the entry point was located.
So a question:
What happens next time User2 triggers an entry point for this application?
Solution:
Use Registry1 (a HKCU registry entry) as keypath instead as user registry hives are only loaded/present when the user is logged in.
Lets give an example
Package content:
Component1 -> KeyPath=File1
File1: [ProgramFilesFolder]MyAppName\Main.exe
Shortcut1: MyAdvertisedShortcutForFile1
Component2 -> KeyPath=File2
File2: [AppDataFolder]MyAppName\data.bin
Registry1: HKCU\Software\MyAppName\MyRegEntry="MyRegValue"
When the package is installed the keypath metadata for Component2 is written to the registry which will point under the %APPDATA% directory for the user whom installed the package.
When a user triggers an entrypoint (in this case Shortcut1) windows installer will check for broken components; will look something like: get keypath from metadata registry, verify if it exists or not, if missing notify to perform a repair.
Should a repair occur the keypath metadata will be rewritten to point to the resolved keypath (ComponentPath).
Lets go through a two-user logon application launch scenario:
User1 logon to the computer and launches Shortcut1, as it's the first time the user uses the application a repair will occur (due to this package design), a so called user profile-fix.
The keypath metadata for Component2 will be written to the registry with a value of "C:\Documents and Settings\User1\Application Data\MyAppName\data.bin".
User2 logon and launches the Shortcut1; same user profile-fix will occur as for User1 however, the keypath metadata value for Component2 will now hold "C:\Documents and Settings\User2\Application Data\MyAppName\data.bin".
User1 logon again and starts the application by an entry point (Shortcut1), the windows installer resiliency feature steps in for a "sanity" check.
When Component2 is checked windows installer will once again get the keypath (ComponentPath) from the windows installer metadata present in the registry and verifies if the component is broken (missing or corrupt keypath). The keypath metadata held in the registry currently have a value of "C:\Documents and Settings\User2\Application Data\MyAppName\data.bin". Windows installer tries to access the file located in another user's profilepath (remember, this will happen in the user context whom triggered the repair) which will fail as regular users do not have access to other user's profiles. Failing to access a file due to permission or file isn't present will make no difference for windows installer and therefore thinks the file doesn't exist. Windows installer will now notify that the "package" needs to be repaired as a component was found broken.
Windows installer will now perform a reinstall of the package: on feature or component level depending on where the broken component and the entry point was located.
So a question:
What happens next time User2 triggers an entry point for this application?
Solution:
Use Registry1 (a HKCU registry entry) as keypath instead as user registry hives are only loaded/present when the user is logged in.
Posted by:
anonymous_9363
14 years ago
The classes were originally registered in HKCU, yes, which seems to be the default place for Windows Installer to put them when using the CLASS table.If the install is per-user, then HKCU will be used. Other than that, it'll always be HKLM.
If you're going to be using the advertising tables, avoid the SelfReg table. Apart from its usage being The Spawn Of The Devil, a) you're duplicating work and, much more importantly, b) registration may fail if the target DLL/OCX has a dependency which is missing.
As a Wise user, you'll have the WiseComCapture utility. Use that to create a .REG. Import the .REG and answer 'Yes' when Wise asks if you want to use the advertising tables. This relies on your having set the appropriate options that instruct Wise to do that (Tools/Options/Advertising).
Posted by:
anonymous_9363
14 years ago
What’s the point in having these exact settings in both the CLASS and Registry tables?None. A lazy (or inexperienced) packager left them there, in all likelihood.
Explanation-wise, you could do worse than taking a look at John McFadyen's blog entries on Windows Live. I would post a link but WL is blocked by my current client. Google him and the blog will turn up.
Posted by:
dreyer
14 years ago
Hello again,
Thank you very much for two helpful responses, I appreciate it.
I’ve read your linked sources and gained a bit more insight, however all is not yet clear.
Now, to gain a better understanding of what this actually means in practice let’s return to my little test setup. More specifically I want to understand the self-heal trigger mechanism.
Maybe I am completely not getting it, but I would expect that I could trigger a self-repair by deleting one of the registry keys generated by the class table. So let’s try that:
The above are the original settings; let’s delete the ThreadingModel and (default) values.
Now, let’s click on the advertised shortcut for the application:
Hmm, nothing, calc.exe just launched. Am I missing something? Is my package broken? Hmm, ok, I try deleting the ENOMFileTransfer.dll file (KeyPath) on the local system and press the shortcut once more. Ah, it triggers a repair and reinstalls the ENOMFileTransfer.dll file.
But wait, look it also repaired the registry settings:
Okay, so from this I conclude there is no special self-heal ability that is exclusive to the CLASS/ProgID/Extension table which I first thought was the case. Self heal’s only occur if the KeyPath is missing (wrong version etc…) no matter what. The only difference is that advertising info tables can trigger self-heals via the hash hook value (right?).
I’m thinking that this will only trigger a repair if an application is doing an action that forces it to go look for whatever it’s supposed to do with that .dll file under that registry key. Sort of like:
Application: Hey! I need this object under {192BA816-9ED5-4FA0-B614-EC1CE77FE3D6}
Application: Uh oh, there seems to be information missing here, better call Windows Installer.
Application: 555-WIN-INSTALLER, “Windows Installer customer support, how may I help you?†Yar, so like I’m missing some COM object information under {192BA816-9ED5-4FA0-B614-EC1CE77FE3D6}, the hook ID is GW-+IGK^CA1e@P[tLS(7>(K0`kxYM?@J(M`5bgC9e, can you fix it for me?
Windows Installer: Sure thing, coming right up!
I’m sure that’s just retarded but I need to figure out how this actually works :)
In essence I’m wondering what is the trigger mechanism for self-heals via the CLASS entries? How does the application communicate this with Windows Installer? Is it possible to give me an example that I can use and manipulate my self to manually trigger the self-heal resilience via the advertising info?
Thanks for reading!
Best wishes,
dreyer
Thank you very much for two helpful responses, I appreciate it.
I’ve read your linked sources and gained a bit more insight, however all is not yet clear.
It's exacly that, it's actually an encoded representation of the combination Application-Feature-Component that's associated with the entry. It's a "hook" for Windows Installer to verify installation integrity (self-heal). It's also called a Darwin Descriptor
Now, to gain a better understanding of what this actually means in practice let’s return to my little test setup. More specifically I want to understand the self-heal trigger mechanism.
Maybe I am completely not getting it, but I would expect that I could trigger a self-repair by deleting one of the registry keys generated by the class table. So let’s try that:
The above are the original settings; let’s delete the ThreadingModel and (default) values.
Now, let’s click on the advertised shortcut for the application:
Hmm, nothing, calc.exe just launched. Am I missing something? Is my package broken? Hmm, ok, I try deleting the ENOMFileTransfer.dll file (KeyPath) on the local system and press the shortcut once more. Ah, it triggers a repair and reinstalls the ENOMFileTransfer.dll file.
But wait, look it also repaired the registry settings:
Okay, so from this I conclude there is no special self-heal ability that is exclusive to the CLASS/ProgID/Extension table which I first thought was the case. Self heal’s only occur if the KeyPath is missing (wrong version etc…) no matter what. The only difference is that advertising info tables can trigger self-heals via the hash hook value (right?).
I’m thinking that this will only trigger a repair if an application is doing an action that forces it to go look for whatever it’s supposed to do with that .dll file under that registry key. Sort of like:
Application: Hey! I need this object under {192BA816-9ED5-4FA0-B614-EC1CE77FE3D6}
Application: Uh oh, there seems to be information missing here, better call Windows Installer.
Application: 555-WIN-INSTALLER, “Windows Installer customer support, how may I help you?†Yar, so like I’m missing some COM object information under {192BA816-9ED5-4FA0-B614-EC1CE77FE3D6}, the hook ID is GW-+IGK^CA1e@P[tLS(7>(K0`kxYM?@J(M`5bgC9e, can you fix it for me?
Windows Installer: Sure thing, coming right up!
I’m sure that’s just retarded but I need to figure out how this actually works :)
In essence I’m wondering what is the trigger mechanism for self-heals via the CLASS entries? How does the application communicate this with Windows Installer? Is it possible to give me an example that I can use and manipulate my self to manually trigger the self-heal resilience via the advertising info?
Thanks for reading!
Best wishes,
dreyer
Posted by:
captain_planet
14 years ago
I had similar questions once upon a time: http://itninja.com/question/unattended-voloview-1x-&-2x-uninstall14&mpage=1&key=captain%5Fplanetꆂ [:D]
Posted by:
dreyer
14 years ago
Hey captain_planet, that helped a lot, thanks mate!
I think I understand this quite a lot better now, however I’ve found something I don’t quite understand. I used your example with scrrun.dll and FileScripting Object to run a manual self heal trigger test.
So I created my self a new dummy .msi:
The VBScript file is simply:
[font="times new roman"]
If the FileScripting object does not work the VBSript will throw an error.
Now I add the desired entry point for FSO:
(I just stole this from another package I knew had scrrun.dll. Is there a very easy way to extract the com information necessary?)
Now, I only want the FSO part of scrrun.dll to serve as an entry point in my test, and it won’t work unless the additional com information for scrrun.dll are also registered. Therefore I add the scrrun.dll to the SelfReg table:
I realize this will probably mean that some of the information in the CLASS table is then overwritten when it runs the registration, but I can’t see what difference it makes seeing as the information is identical. Also, the Entry point (Darwin Descriptor) shouldn’t be touched by the self-registration.
Great, the test package is ready, let’s install and observe the changes:
We can see the entry point (Darwin Descriptor) is there and everything looks good.
I observe that the registry settings from the CLASS table are placed under HKCU.
To start off I double click the FSO.vbs script to make sure everything is working:
Great!
Now I delete the scrrun.dll file and double click the FSO.vbs file again.
Great, it starts the self-heal process and re-installs the scrrun.dll file!
Lets try that again just in case:
What the? It stopped self-healing! It no longer works. What’s happened?
Well, after running an additional test, this is what occurred after the first self-heal:
The settings from the CLASS table that were installed to HKCU are GONE and the Darwin Descriptor is gone. In fact, the entire GUID is gone from HKCU and is now simply present in HKLM.
I then uninstall my dummy package (I manually unregister scrrun.dll first), edit the Self-Reg table and remove scrrun.dll.
I reinstall my dummy package and test the FSO.vbs:
OK, that was expected.
Now I register scrrun.dll manually and try again; great it works now as expected.
I check the registry settings again:
Great, the Darwin Descriptor is there. Now lets delete scrrun.dll and test again:
Yes, it self-heals and reinstalls the scrrun.dll.
Again? [Deletes scrrun.dll]
Yes, works again now! And the Darwin Descriptor from the CLASS table remains intact in the registry.
Okey, lets try to register the scrrun.dll file manually AGAIN even though it’s already registered and working (I just figured out this at the end of writing this freaking post):
Gone are the class settings from HKCU but RegSrv32 has installed them exclusively to HKLM.
Doh! Why does registering a .dll file after it already has been registered cause this? Means that you can’t use self-reg for a .dll you want to include one or more entry points for. I’m forced to manually extract all the self-reg com information and put it into the registry table.
Is this by design?
Regards,
dreyer
I think I understand this quite a lot better now, however I’ve found something I don’t quite understand. I used your example with scrrun.dll and FileScripting Object to run a manual self heal trigger test.
So I created my self a new dummy .msi:
The VBScript file is simply:
[font="times new roman"]If the FileScripting object does not work the VBSript will throw an error.
Now I add the desired entry point for FSO:
(I just stole this from another package I knew had scrrun.dll. Is there a very easy way to extract the com information necessary?)
Now, I only want the FSO part of scrrun.dll to serve as an entry point in my test, and it won’t work unless the additional com information for scrrun.dll are also registered. Therefore I add the scrrun.dll to the SelfReg table:
I realize this will probably mean that some of the information in the CLASS table is then overwritten when it runs the registration, but I can’t see what difference it makes seeing as the information is identical. Also, the Entry point (Darwin Descriptor) shouldn’t be touched by the self-registration.
Great, the test package is ready, let’s install and observe the changes:
We can see the entry point (Darwin Descriptor) is there and everything looks good.
I observe that the registry settings from the CLASS table are placed under HKCU.
To start off I double click the FSO.vbs script to make sure everything is working:
Great!
Now I delete the scrrun.dll file and double click the FSO.vbs file again.
Great, it starts the self-heal process and re-installs the scrrun.dll file!
Lets try that again just in case:
What the? It stopped self-healing! It no longer works. What’s happened?
Well, after running an additional test, this is what occurred after the first self-heal:
The settings from the CLASS table that were installed to HKCU are GONE and the Darwin Descriptor is gone. In fact, the entire GUID is gone from HKCU and is now simply present in HKLM.
I then uninstall my dummy package (I manually unregister scrrun.dll first), edit the Self-Reg table and remove scrrun.dll.
I reinstall my dummy package and test the FSO.vbs:
OK, that was expected.
Now I register scrrun.dll manually and try again; great it works now as expected.
I check the registry settings again:
Great, the Darwin Descriptor is there. Now lets delete scrrun.dll and test again:
Yes, it self-heals and reinstalls the scrrun.dll.
Again? [Deletes scrrun.dll]
Yes, works again now! And the Darwin Descriptor from the CLASS table remains intact in the registry.
Okey, lets try to register the scrrun.dll file manually AGAIN even though it’s already registered and working (I just figured out this at the end of writing this freaking post):
Gone are the class settings from HKCU but RegSrv32 has installed them exclusively to HKLM.
Doh! Why does registering a .dll file after it already has been registered cause this? Means that you can’t use self-reg for a .dll you want to include one or more entry points for. I’m forced to manually extract all the self-reg com information and put it into the registry table.
Is this by design?
Regards,
dreyer
Posted by:
anonymous_9363
14 years ago
Why does registering a .dll file after it already has been registered cause this?You mean by using RegSrv32?
Remember that HKCR is an amalgam of HKLM\Software and HKCU\Software. RegSvr32 defaults to writing to the HKLM hive. Were your classes originally registered in HKCU?
Is there a very easy way to extract the com information necessary?What authoring tool are you using?
Posted by:
dreyer
14 years ago
ORIGINAL: VBScab
Why does registering a .dll file after it already has been registered cause this?You mean by using RegSrv32?
Yes, I guess I do. I assume RegSrv32 is also the tool that registers .dll files when it's done via the Self-Reg table in an .msi? They seem to produce exactly the same results in this case at least.
ORIGINAL: VBScab
Remember that HKCR is an amalgam of HKLM\Software and HKCU\Software. RegSvr32 defaults to writing to the HKLM hive. Were your classes originally registered in HKCU?Is there a very easy way to extract the com information necessary?What authoring tool are you using?
Aye I know that, unless I mistyped I did not mention HKCR in the previous post.
The classes were originally registered in HKCU, yes, which seems to be the default place for Windows Installer to put them when using the CLASS table. I'm guessing the only reason they even showed up in registry after the first installation must be that the MSI action that runs the Self-Reg under InstallExecuteSequence is launched BEFORE the action responsible for installing the CLASS settings but then during a maintenance install (repair) this is no longer the case. Otherwise I would assume that the class entries would never be installed (or be installed and immediately removed by Self-Reg before the .msi installer finishes).
I used Wise 7.0 SP2 to create a empty template dummy package and then I used InstEdit to modify it.
Posted by:
dreyer
14 years ago
ORIGINAL: dreyer
I'm guessing the only reason they even showed up in registry after the first installation must be that the MSI action that runs the Self-Reg under InstallExecuteSequence is launched BEFORE the action responsible for installing the CLASS settings but then during a maintenance install (repair) this is no longer the case. Otherwise I would assume that the class entries would never be installed (or be installed and immediately removed by Self-Reg before the .msi installer finishes).
That makes no sense either because action RegisterClassInfo is executed before SelfRegModules, which leaves me wondering why the hell it works at all after the first install before the triggered self-heal.
Posted by:
dreyer
14 years ago
ORIGINAL: VBScab
The classes were originally registered in HKCU, yes, which seems to be the default place for Windows Installer to put them when using the CLASS table.If the install is per-user, then HKCU will be used. Other than that, it'll always be HKLM.
If you're going to be using the advertising tables, avoid the SelfReg table. Apart from its usage being The Spawn Of The Devil, a) you're duplicating work and, much more importantly, b) registration may fail if the target DLL/OCX has a dependency which is missing.
As a Wise user, you'll have the WiseComCapture utility. Use that to create a .REG. Import the .REG and answer 'Yes' when Wise asks if you want to use the advertising tables. This relies on your having set the appropriate options that instruct Wise to do that (Tools/Options/Advertising).
Oh, how nice, Wise is actually useful for a change :) Thank you for the tip!
I'm very accustomed to using the Self-Reg table, even though I'm aware of it's problems. The policy of the business that I'm scripting for is basically "don't you freaking put anything in the damned CLASS, PROGID tables, because it can cause random self-repairs!!". Those who check the packages that are scripted are even beginning to ask us to remove CLASS/PROGID information from original vendor .msi files, which was really the major reason I wanted to learn more about it because I was fairly confident these rules were just made up due to a lack of understanding.
We've never (as far as I know) experienced your scenario "B" though in production though. Those problems are generally sorted out before hand while scripting and since we operate with just a single standard operating system environment which is equal for everyone, it's never really been a problem. Also, putting COM information in the registry is also more or less forbidden here. Also, Selg-Reg .dll's cannot be registered to Program Files, as application folders are locked down and as such could cause problems for users that log on to any given machine without access to a folder where a common component .dll is located.
Do you stick to using the advertising info tables even for packages that are meant to be distributed on Terminal Services?
Posted by:
Jsaylor
14 years ago
Just to note:
This is a fantastic thread, kudos to Dreyer here for posting thorough questions. EDIT: and being a delicious ice cream.
Upvotes and/or hugs all around.
This is a fantastic thread, kudos to Dreyer here for posting thorough questions. EDIT: and being a delicious ice cream.
Upvotes and/or hugs all around.
Posted by:
anonymous_9363
14 years ago
kudos to Dreyer here for posting thorough questions.Seconded. [sigh]If only others were as thorough in their investigations before they post...[/sigh]
Posted by:
pjgeutjens
14 years ago
The policy of the business that I'm scripting for is basically "don't you freaking put anything in the damned CLASS, PROGID tables, because it can cause random self-repairs!!". Those who check the packages that are scripted are even beginning to ask us to remove CLASS/PROGID information from original vendor .msi files, which was really the major reason I wanted to learn more about it because I was fairly confident these rules were just made up due to a lack of understanding.
Just a curious question:
When you say that using those tables can cause "random self repairs"... do you mean the application itself, or other applications, or maybe the dreaded self repair eternal loop?
Reason why I ask is that I'm suspecting what was previously called "dirty" packages, where components that are actually systemcomponents (or at least have a broader scope than just your package) were included in packages. I don't know the environment you're working in and I don't want to judge at all, but one needs to make a clear distinction between your cleanly installed OS, your prerequisite applications and your packaged application.
I've seen many packages in the past reregistering standard Windows CLSID's, or standard Office stuff, or interfering with another package's registrations, and this IS a cause for headaches. App A repairs, App B goes off and repairs the same stuff, App A again.. you get the picture.
This last thing actually moves the discussion into the realm of Merge Modules and Component Matching between applications, which is a whole other realm.
As for modifying vendor MSI. As much as I often want to, as a rule I keep my hands off em and do any modifications using transforms. You never know when you'll need to patch your app 3 months later and because of some "tweak" it won't patch, leaving you to reengineer and (ofter worse) redistribute the old package.
Just my 2c
PJ
Posted by:
anonymous_9363
14 years ago
Pieter, As I think Sindre already hinted, the decree comes about due to simple ignorance. Some idiot packager probably screwed up one or more packages, blamed the use of the advertising tables to cover his rear and since then, it has been taken to be the perceived wisdom by a management who know no better.
Sindre, retrieve the MEBB (Management Education Baseball Bat) from storage and begin the process. You know it makes sense.
Sindre, retrieve the MEBB (Management Education Baseball Bat) from storage and begin the process. You know it makes sense.
Posted by:
dreyer
14 years ago
ORIGINAL: pjgeutjens
Just a curious question:
When you say that using those tables can cause "random self repairs"... do you mean the application itself, or other applications, or maybe the dreaded self repair eternal loop?
I think I can answer yes to all of the above. The main concern is that a user will experience a self-repair for application A when he is using application B. This is probably due to poor packaging authoring. Though, the reason this controversy started in this business is actually because of Microsoft Visio. On many (or most) of the meeting room PC’s where lots of users log in and out and install their applications Microsoft Visio will trigger a self-repair whenever you for instance launch MS Word or do various actions in MS Word. Self-repair also occurs when users make use of a team site through Internet Explorer etc… Nobody has ever really been able to identify and fix the problem (probably problems as there’s never just a singular trigger). I’m personally guessing that this has to do with other packages being poorly authored and thus interfering with the advertising information present in the MS Visio package. Nobody is really investigating it, it's been like that for years and it's an accepted evil.
But the general consensus appears to be “If Microsoft can’t get it right, and then it’s not trustworthy. This functionality causes more problems than it solves.â€Â
ORIGINAL: pjgeutjens
Reason why I ask is that I'm suspecting what was previously called "dirty" packages, where components that are actually systemcomponents (or at least have a broader scope than just your package) were included in packages. I don't know the environment you're working in and I don't want to judge at all, but one needs to make a clear distinction between your cleanly installed OS, your prerequisite applications and your packaged application.
In this business all repackaged applications are captured on a standard clean operating system with the same configuration that we know all machines in the network is setup with. For instance MSOffice is standard on all machines; therefore captures are made with Office installed first. A common components package (with merge modules) is distributed to all machines as well, so this is installed prior to any captures as well. That’s just two examples.
ORIGINAL: pjgeutjens
I've seen many packages in the past reregistering standard Windows CLSID's, or standard Office stuff, or interfering with another package's registrations, and this IS a cause for headaches. App A repairs, App B goes off and repairs the same stuff, App A again.. you get the picture.
Yes, these things are filtered out through a team responsible for checking packages that come from scripter’s to ensure no problems occur in production. Including Office components in a capture is strictly forbidden.
ORIGINAL: pjgeutjens
This last thing actually moves the discussion into the realm of Merge Modules and Component Matching between applications, which is a whole other realm.
As for modifying vendor MSI. As much as I often want to, as a rule I keep my hands off em and do any modifications using transforms. You never know when you'll need to patch your app 3 months later and because of some "tweak" it won't patch, leaving you to reengineer and (ofter worse) redistribute the old package.
In this business recapturing an .msi vendor setup is strictly forbidden, we are to use a transform file at all times possible. Which I support, I hate captures.
The fear here is that vendor .msi’s still might have poor authoring and advertising info entries that can cause problems (“random†self-repairs) in production and therefore instead of trying to improve the quality of the scripting process they’re instead just not relying on that feature of Windows Installer.
That said, vendor .msi’s that have a large amount of information in the advertising tables are generally allowed to pass.
Does this answer your question?
Thanks for your post.
Best wishes,
dreyer
Posted by:
dreyer
14 years ago
ORIGINAL: Jsaylor
Just to note:
This is a fantastic thread, kudos to Dreyer here for posting thorough questions. EDIT: and being a delicious ice cream.
Upvotes and/or hugs all around.
Thank you, hugs and ice cream is appreciated. I'm getting ice cream, right?! Oh wait...
Posted by:
dreyer
14 years ago
To get back on topic for a bit I'm going to recap a few things I've learned.
(***)
Now here is another question.
After importing the COM information from scrrun.dll and converting the registry information to advertising information I’m left with the appropriate populated Class and ProgID tables in addition to a list of registry keys that wise automatically imported to the registry table. Here’s what Wise has done:
(Small sample)
Now, Wise has created a new component called registry with a registry key as the KeyPath.
Do you recommend this or would you recommend moving all these registry keys to the scrrun.dll component? I would personally assume this would be better (to keep all the information from scrrun.dll in the scrrun.dll component isntead). Thoughts? Feedback is appreciated.
Hi AngelD!
Aye, luckily I’m not that newbie :)
If you use the Registry table, do you always set the component to permanent (not to be removed on uninstall)? In my workplace we’re not really allowed to place COM information in the Registry table (in general).
For vendor .msi’s that come with the advertising tables fully populated, would you recommend then to convert this into registry information and place it in the registry table via a transform file?
Also, users do have permissions to trigger the self-repair, just not to complete it, correct?
I did not really know of DISABLEADVTSHORTCUTS, but I tested it and I see that it just converts the advertised shortcuts in a package to normal shortcuts. This is not really necessary for us as shortcuts on our Terminal Servers are created via Citrix Metaframe and the ones in the package are not actually used. Thank you for the tip though :)
- The advertising tables (CLASS, ProgID, Extensions) basically generate registry keys more or less like it would from the Registry table with one major difference in that it generates a hash value that serves as an entry point for the MSI package. This entry point will then be triggered each time that COM is used and if Windows Installer finds broken components when checking against the KeyPath it will initiate a self-heal (it does not matter if the entry point triggered is the broken component or not).
Hash Value:
Here is an example of advertising information for scrrun.dll in the CLASS table:
- Information in the advertising tables will be installed to HKCU if the installation is per user and to HKLM if the installation is per machine (ALLUSERS=1).
- The RegisterClassInfo action is the action responsible for registering the information in the CLASS table and the other actions for the ProgID and Extensions (self-explanatory).
- If you use the SelfReg table for a .dll file that has entry points via one of the advertising tables (like Class), you will DESTROY the entry points (just tested this) during the installation. SelfRegModules will start after RegisterClassInfo (in the suggested InstallExecuteSequence) and thus it will overwrite all the information (and delete the hash value entry point) that was created by RegisterClassInfo. It does this during both a per user installation and a per machine intallation (ALLUSERS=1).
The same thing happens (without SelfReg table) if you run regsvr32 on the .dll file manually after installation.
You can change the InstallExecuteSequence and place RegisterClassInfo after SelfRegModules and this will work just fine (just manually tested it). However, it’s rather stupid (as pointed out by the fine gentlemen in this thread) and I don’t recommend using the Self-Reg table in this manner.
- There is no property to disable Windows Installer from creating the entry point hash values associated with the advertising table. However, I know it’s possible to write a fairly complicated script that can tell what advertising information your package installs and deletes all the hash values accordingly before installation finishes through a Custom Action. This is a possibility.
- If you are a user of Wise Package Studio you can use WiseComCapture.exe to capture the COM information for a .dll/.ocx file. This will compile a .reg file that can be used to import into the registry via Wise. When asked if you want to scan for advertising information and turn this registry information in to advertising information you can press YES and the CLASS/ProgID tables (etc.) will be populated for you (quite handy).
As a side note, does anyone know of easy tools (perhaps free?) that can accomplish this aside from Wise/InstallShield? Input is appreciated.
Also understand that most COM objects have registry information that is not suited as advertising information and this will need to be placed in the registry table. (***)
(***)
Now here is another question.
After importing the COM information from scrrun.dll and converting the registry information to advertising information I’m left with the appropriate populated Class and ProgID tables in addition to a list of registry keys that wise automatically imported to the registry table. Here’s what Wise has done:
(Small sample)
Now, Wise has created a new component called registry with a registry key as the KeyPath.
Do you recommend this or would you recommend moving all these registry keys to the scrrun.dll component? I would personally assume this would be better (to keep all the information from scrrun.dll in the scrrun.dll component isntead). Thoughts? Feedback is appreciated.
ORIGINAL: AngelD
Hi dreyer,
The B scenario Ian mentioned will mostly happen when you repackage on a non-clean machine and later try to install on a corporate client missing the dependent DLL that existed on the "dirty" packaging machine ;) This is a common newbie mistake.
Hi AngelD!
Aye, luckily I’m not that newbie :)
ORIGINAL: AngelD
Remove away from any kind of self registration for COM-components, either use COM advertising (which you're currently trying to grip) or the Registry table.
If you use the Registry table, do you always set the component to permanent (not to be removed on uninstall)? In my workplace we’re not really allowed to place COM information in the Registry table (in general).
ORIGINAL: AngelD
When it comes to Terminal Service/Citrix environment forget about advertisement, users do not have permission to trigger a self-repair. So in the case of TS/Citrix use the Registry table instead, make sure shadow registry takes care of any HKCU entry or by logon script, the latter for any files in the userprofile. You should also use the DISABLEADVTSHORTCUTS property in case of.
For vendor .msi’s that come with the advertising tables fully populated, would you recommend then to convert this into registry information and place it in the registry table via a transform file?
Also, users do have permissions to trigger the self-repair, just not to complete it, correct?
I did not really know of DISABLEADVTSHORTCUTS, but I tested it and I see that it just converts the advertised shortcuts in a package to normal shortcuts. This is not really necessary for us as shortcuts on our Terminal Servers are created via Citrix Metaframe and the ones in the package are not actually used. Thank you for the tip though :)
Posted by:
AngelD
14 years ago
"Also, users do have permissions to trigger the self-repair, just not to complete it, correct?"
Yes, thanks for correcting me :)
"For vendor .msi’s that come with the advertising tables fully populated, would you recommend then to convert this into registry information and place it in the registry table via a transform file?"
1. If you are repackaging only for a TS environment then I would skip any advertising info.
2. If the package should work a TS environment and a client operating system (ex. XP, Vista...)
2a. add the advertising info
2b. make sure any required component resource is present before an entry point is called.
3. For vendor packages; perform any modifications through a transform and refer to 2b.
Yes, thanks for correcting me :)
"For vendor .msi’s that come with the advertising tables fully populated, would you recommend then to convert this into registry information and place it in the registry table via a transform file?"
1. If you are repackaging only for a TS environment then I would skip any advertising info.
2. If the package should work a TS environment and a client operating system (ex. XP, Vista...)
2a. add the advertising info
2b. make sure any required component resource is present before an entry point is called.
3. For vendor packages; perform any modifications through a transform and refer to 2b.
Posted by:
dreyer
14 years ago
User1 logon again and starts the application by an entry point (Shortcut1), the windows installer resiliency feature steps in for a "sanity" check.
When Component2 is checked windows installer will once again get the keypath (ComponentPath) from the windows installer metadata present in the registry and verifies if the component is broken (missing or corrupt keypath). The keypath metadata held in the registry currently have a value of "C:\Documents and Settings\User2\Application Data\MyAppName\data.bin". Windows installer tries to access the file located in another user's profilepath (remember, this will happen in the user context whom triggered the repair) which will fail as regular users do not have access to other user's profiles. Failing to access a file due to permission or file isn't present will make no difference for windows installer and therefore thinks the file doesn't exist. Windows installer will now notify that the "package" needs to be repaired as a component was found broken.
Windows installer will now perform a reinstall of the package: on feature or component level depending on where the broken component and the entry point was located.
Does not this exact process also occur for the first login of User2 after User1 has been on the system once?
So a question:
What happens next time User2 triggers an entry point for this application?
As far as I understand your example as long as User1 and User2 keeps switching and logging on one after each other and triggers the advertised shortcut a repair will occur on the first trigger of every session. Sort of like a battle of the metadata keypath values for Windows Installer in registry? I.e. changing the metadata present in the registry for the component back and forth between "C:\Documents and Settings\User1\Application Data\MyAppName\data.bin" and "C:\Documents and Settings\User2\Application Data\MyAppName\data.bin" in between login sessions?
Posted by:
dreyer
14 years ago
ORIGINAL: AngelD
1. If you are repackaging only for a TS environment then I would skip any advertising info.
Assuming you are creating a transform for an original vendor setup that includes a large amount of entries under the Class/ProgID tables. How do you go about converting this information to the registry table? Obviously you can't just delete the Class/ProgID entries as that will cause the application to probably stop working. Do you have a best practice for such a task other than just doing it manually line for line?
Posted by:
anonymous_9363
14 years ago
How do you go about converting this information to the registry table?For me, the shortest route is to:
- export the COM information into .REG files
- delete the advertising tables
- import the .REGs
WPS makes the above simpler, particularly if you script the first part, using WiseComCapture.
Posted by:
dreyer
14 years ago
ORIGINAL: VBScab
How do you go about converting this information to the registry table?For me, the shortest route is to:
- export the COM information into .REG files
- delete the advertising tablesÂÂ
- import the .REGs
WPS makes the above simpler, particularly if you script the first part, using WiseComCapture.
Only problem I foresee with that is that you'll then probably have a lot of duplicate entries in the Registry table for those COM objects. If you look at for instance scrrun.dll, only a small amount of the registry keys are advertising information and the rest is located in the registry table. You'll then have to clean out those settings from the registry table as well, lest you want duplicate settings?
Posted by:
dreyer
14 years ago
ORIGINAL: VBScab
Duplicates? Where, if the advertising tables are empty?
Okey, lets say that a original vendor .msi has scrrun.dll and uses the advertising tables and includes all the registry information neccessary for the dll to register properly. This then includes settings in CLASS, PROGID and the Registry Table. Such as:
CLASS:
REG:
If you then use WiseComCapture with scrrun.dll to create a .reg file with all the registry information for that .dll with the intention of importing all of it into the Registry table then you'll either have to manually delete the registry keys present in the image above in the .msi file (using a .mst) or delete them in the .reg file before import as otherwise you'll get duplicate entries in two separate components. Does this make sense?
Only the registry keys that were generated in the original vendor msi's from CLASS/ProgID table will NOT be duplicated when you import your .reg file generated from WiseComCapture.
I suppose, if the scrrun.dll in the original vendor .msi was in it's OWN isolated component, you could just delete the entire component, but if not, you'll have to manually sort it out... or am I missing something obvious here?
EDIT: OK, I think the obvious thing I'm missing here is that Wise is actually smart enough to not import and duplicate settings like so:
Wise rather appears to delete the keys that are already present and generate new ones. Which is evident by the new registry keyname values after import (looking in the .msi file before import registry key values are numbered 1-74 and after import they're numbered 75-190).
Posted by:
AngelD
14 years ago
"Does not this exact process also occur for the first login of User2 after User1 has been on the system once?"
Yes, just wanted to point out that even if the profile-fix has been triggered once it can be triggered everytime the user launches the application.
The battle of the Windows Installer metadata.... DAMN; that would have been a nice topic [:D]
"How do you go about converting COM advertising from vendor MSI"
1. You don't
"1. If you are repackaging only for a TS environment then I would skip any advertising info."
repackaging=capture
2. If you would want to "convert" then do the following through a transform
Remove every Class/ProgID.... entry
Extract the registry using WiseComCapture.exe and select use registry as-is (not advertising information)
Yes, just wanted to point out that even if the profile-fix has been triggered once it can be triggered everytime the user launches the application.
The battle of the Windows Installer metadata.... DAMN; that would have been a nice topic [:D]
"How do you go about converting COM advertising from vendor MSI"
1. You don't
"1. If you are repackaging only for a TS environment then I would skip any advertising info."
repackaging=capture
2. If you would want to "convert" then do the following through a transform
Remove every Class/ProgID.... entry
Extract the registry using WiseComCapture.exe and select use registry as-is (not advertising information)
Posted by:
pjgeutjens
14 years ago
If you then use WiseComCapture with scrrun.dll to create a .reg file with all the registry information for that .dll with the intention of importing all of it into the Registry table then you'll either have to manually delete the registry keys present in the image above in the .msi file (using a .mst) or delete them in the .reg file before import as otherwise you'll get duplicate entries in two separate components. Does this make sense?
When importing a reg file in your MSI you should get a chance to determine how to handle duplicate entries (overwrite or not with your new values), so you won't actually have any duplicates in your package. So in essence emptying out Class and SelfReg tables and importing the reg file containing the COM info will give you a unified situation. The imported Reg entries will replace the advertised entries and existing Reg table entries, not be added as duplicates.
EDIT: Just saw your edit on your post saying just about this [:D]
PJ
Posted by:
dreyer
14 years ago
2. If you would want to "convert" then do the following through a transform
Remove every Class/ProgID.... entry
Extract the registry using WiseComCapture.exe and select use registry as-is (not advertising information)
If anyone have any good ideas of how to complete the above process without the need to use Wise Installer Editor I would appreciate it. Using the tool WiseComCapture.exe is fine, however I really don't want to use Wise to edit my already clean and ordered .mst file using Wise and having it add all sorts of custom actions and rubbish I don't want in there. Additionally trying to compile a .mst for a really large package takes forever.
I'm thinking I'm going to just create a Wise dummy package and import the registry settings and compile and then use InstEd to copy/paste the row's from the Registry table and then manually change the component the keys are present in by copy-pasting (which is fairly quick in InstEdit even if you have like 100 rows; anyone know how to change the component for multiple rows in one sweep?).
On a side note I want to take the time to thank everyone who has contributed to this thread. I feel I've learned a lot and now have a fairly good understanding of the topic. Thanks everyone!
Posted by:
anonymous_9363
14 years ago
ll sorts of custom actions and rubbish I don't wantWhat CAs would they be? I can't find any which WPS added to any of my projects. The "rubbish" consists of 10 tables which take, what, a second to delete?
The only other course open to you, I think, would be to build a script to update the Registry table using WI's automation. Best of luck with that! :)
Posted by:
dreyer
14 years ago
ORIGINAL: VBScab
ll sorts of custom actions and rubbish I don't wantWhat CAs would they be? I can't find any which WPS added to any of my projects. The "rubbish" consists of 10 tables which take, what, a second to delete?
The only other course open to you, I think, would be to build a script to update the Registry table using WI's automation. Best of luck with that! :)
Things like these are added:
Just check out the difference in size on the .mst file before and after a Wise compilation:
But like you said, it's not the end of the world, they can all be manually deleted and cleaned. It's just annoying to have to do that after each compile. The time it takes to compile a .mst for a large package is worse in my opinion.
I don't want there to be anything in my .mst's in green (new) that I have not put there purposely. Hehe....
Posted by:
anonymous_9363
14 years ago
I meant that you could continue with Orca/InstEdit (both of which will slim the MST back down again, I think) for day-to-day stuff but use WPS to import the .REGs when there are lots of them.
Posted by:
abking99
14 years ago
Hi,
I know my post is too let, but still I wanted to clear this.
http://sites.google.com/site/msisnaps/snaps/snaps.JPG?attredirects=0
In the above snap we can see, same set of registries, in advertising table and in registry section.
1) So can we say that, entries from registry table are not required?
I know my post is too let, but still I wanted to clear this.
http://sites.google.com/site/msisnaps/snaps/snaps.JPG?attredirects=0
In the above snap we can see, same set of registries, in advertising table and in registry section.
1) So can we say that, entries from registry table are not required?
Posted by:
anonymous_9363
14 years ago
You need to open out the CLSID entries before deleting them, since they could be entries like 'HelpDir' which need to stay intact.
As long as you set up WPS to use the advertising tables INSTEAD OF the registry and always select 'Yes' to do the same when importing .REG files, you shouldn't ever get duplicates. For vendor MSIs, [controversial_statement]leave them alone. [/controversial_statement]
As long as you set up WPS to use the advertising tables INSTEAD OF the registry and always select 'Yes' to do the same when importing .REG files, you shouldn't ever get duplicates. For vendor MSIs, [controversial_statement]leave them alone. [/controversial_statement]
Posted by:
abking99
14 years ago
What ever I learn till today, is....self repair, advertisement, ice33, registration, extensions, all are relevant to each other. If we classify it then i know each individual perfectly, but if you ask me to combine all the things and explain, then gone!!! below are some links which i studied
http://robmensching.com/blog/posts/2007/3/12/RobMens-Recommendation-Do-not-advertise-COM-information-in-MSI
http://johnmcfadyen.spaces.live.com/?_c11_BlogPart_BlogPart=summary&_c=BlogPart
http://itninja.com/question/redeploy-sms-advanced-client-(2003)2
Still some doubts are not cleared...
1) What is the exact benefit of advertising registry? when we are importing comdata in our package, wps prompts us for advertising registries, if we select no, then also registries are imported, and package will still work...
2) One of the above link,[robmensching.com] saying com registration should not be used.
3) Self registration is also not advised as "Rollback of an installation with self-registered modules cannot be safely done"
4) If we are keeping selfreg entries and install msi, them it will be a self registration, if we register each entry with the help of wisecomcapture, and import it's comdata with advertising registries, it will be comregistration. Am i right?
Please understand, not only me but there are so many people which have this confusion...and believe me these confusions can be solved only on appdeploy, nowhere else...
http://robmensching.com/blog/posts/2007/3/12/RobMens-Recommendation-Do-not-advertise-COM-information-in-MSI
http://johnmcfadyen.spaces.live.com/?_c11_BlogPart_BlogPart=summary&_c=BlogPart
http://itninja.com/question/redeploy-sms-advanced-client-(2003)2
Still some doubts are not cleared...
1) What is the exact benefit of advertising registry? when we are importing comdata in our package, wps prompts us for advertising registries, if we select no, then also registries are imported, and package will still work...
2) One of the above link,[robmensching.com] saying com registration should not be used.
3) Self registration is also not advised as "Rollback of an installation with self-registered modules cannot be safely done"
4) If we are keeping selfreg entries and install msi, them it will be a self registration, if we register each entry with the help of wisecomcapture, and import it's comdata with advertising registries, it will be comregistration. Am i right?
Please understand, not only me but there are so many people which have this confusion...and believe me these confusions can be solved only on appdeploy, nowhere else...
Posted by:
instedit
14 years ago
ORIGINAL: dreyer
Hi dreyer,
I know this post is quite old now, but for what it's worth you have several options to achieve what you wanted with InstEd.
You can import a registry file directly into a component using the Component view: http://apps.instedit.com/importing.regfiles.html
Or, if you have copied the rows already and they are all in one component, you can use a variation of this method to change their component all at once: http://blog.instedit.com/2008/09/tips-and-tricks-part-4-moving-component.html
In summary, for your exact situation,
1: Ensure row reference tracking is enabled.
2: Rename the target component to the component name that all the registry rows have, but don't update any references (deselect everything in Update Referencing Rows dialog).
3: Rename the component again back to it's original name, and just click OK to update all the referencing rows.
The target component will then have all the new registry rows correctly referencing it, as well as all the stuff it originally had.
Finally, you can sort the registry rows by component and then cut/paste them into Excel (and probably other spreadsheets). From there, use it's fill down mechanism to quickly update all the relevant component entries. Then copy/paste the rows back into the registry table.
Hope this helps.
...
I'm thinking I'm going to just create a Wise dummy package and import the registry settings and compile and then use InstEd to copy/paste the row's from the Registry table and then manually change the component the keys are present in by copy-pasting (which is fairly quick in InstEdit even if you have like 100 rows; anyone know how to change the component for multiple rows in one sweep?).
...
Hi dreyer,
I know this post is quite old now, but for what it's worth you have several options to achieve what you wanted with InstEd.
You can import a registry file directly into a component using the Component view: http://apps.instedit.com/importing.regfiles.html
Or, if you have copied the rows already and they are all in one component, you can use a variation of this method to change their component all at once: http://blog.instedit.com/2008/09/tips-and-tricks-part-4-moving-component.html
In summary, for your exact situation,
1: Ensure row reference tracking is enabled.
2: Rename the target component to the component name that all the registry rows have, but don't update any references (deselect everything in Update Referencing Rows dialog).
3: Rename the component again back to it's original name, and just click OK to update all the referencing rows.
The target component will then have all the new registry rows correctly referencing it, as well as all the stuff it originally had.
Finally, you can sort the registry rows by component and then cut/paste them into Excel (and probably other spreadsheets). From there, use it's fill down mechanism to quickly update all the relevant component entries. Then copy/paste the rows back into the registry table.
Hope this helps.
Posted by:
anonymous_9363
14 years ago
Why would you think that? Uninstallation will remove any installed registry components which, unless they're marked to remain installed, will get uninstalled just like all the rest of the components.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.