I'm installing an Active X control that contains some COM servers. I'm using InstallShield's COM Extract at Build option to generate the registry information. This results in a lot of entries in the Registry and Class tables. (The extracted information is pretty much the same using Wix).
It appears that my COM Sever is correctly being installed except for an additional value called "InprocServer32" in the InprocServer32 key that looks like this:
HKCR\CLSID\{MY-COM-GUID}\InprocServer32
(Default) = C:\Path-to-my\file.ocx
InprocServer32 = 8tYCAGak)9S9&~swl.$?MyFeatureName>*&N$B'fk?As1x2J653?'
The only think I can make out from the extra value is the MyFeatureName which is the internal name of the MSI feature that contains the .ocx file. The key is not listed in the Registry table so it must be generated by the Class table.
The problem I'm having only happens in Windows Server 2008. It seems that the app trying to use the COM server is failing to find the path to the .ocx file from the (Default) value and instead it is finding the InprocServer32 value. This results in the app launching the MSI and then having the MSI being stuck in what seems like an infinte loop.
I'm wondering if this is a known issue in Windows Server 2008 or whether there is a way to prevent that extra value from being generated by msiexec.
I'd read this article and see if it helps you get where you want to be:
RobMen's Recommendation: Do not advertise COM information in MSI
You might want to turn off InstallShield's COM Extract at Build and instead do a One-Time COM Extract on the component in question. Then you can go into the Component Advanced section and manually manipulate the registry / com table information to be how you want it to be.
If you use WiX at all, another workflow / trick is to use Heat to build an MSI or MSM around your COM server. Then use InstallShield to edit the MSI/MSM in direct mode and the Registry view to export the Registry Keys/Values to a .REG file. Then import that .REG file into your Component in your real install project.
I can't help you diagnose what's going on, I'll just mumble a bit about what this all means. This is a counter-measure against DLL Hell. It is supposed to protect your application against some kind of other install program that could overwrite your COM server registry keys. Specifically the (Default) key which gives the location to your server DLL.
From the fake InprocServer32 value, the app can auto-detect that the Default key was overwritten and automatically launch MSI again to repair the damage. Which is what you see happening.
I thoroughly dislike the feature, it is just one more fail point in something that is already hard to troubleshoot when it blows up. And it is a useless feature, it assumes that the other installer doesn't use the exact same counter-measure. Which would have worked 10 years ago.
No idea what you'd do to troubleshoot this particular failure. Other then just punt this cr*p and let the servers just SelfReg themselves. At least you'll have something to work with when that doesn't work.
Related
In a simple windows form application on VS 2010 I have put a ovalShape using power packs.
The simple Form
Now automatically this action puts the reference of Microsoft.VisualBasic.PowerPacks.Vs in to project properties.
when deploying this in different PC obviously the (a)powerpacks needed to be installed if this application doesn't work, (b) or it can set to "copy local = true" in reference properties so that it should sit to next with the application.
assuming (b) is not an option, since it is a solitary executable, (a) is the only option. in this way if the target machine does not have powerpacks the requirement is to notify it to the user in the first place.
apparently the dll will be deployed in when using the "VisualBasicPowerPacksSetup"
C:\Windows\assembly\GAC_MSIL\Microsoft.VisualBasic.PowerPacks.Vs\10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualBasic.PowerPacks.Vs.dll
so the blind approach is just to check if the above file not exist then prompt user to install "VisualBasicPowerPacksSetup". but i feel its more accurate if the application able to actually check in registry level.
in registry "Microsoft.VisualBasic.PowerPacks" records in several location, thus makes a confusion.
how to identify the correct key and what should be correct way of checking this reference in vb ?
You could just try to create an object defined in the dependency and catch the resulting exception.
Handling this you could ask the user to install the package. This is probably not considered good practice but should get the job done.
Is there a way to set a property value to the formatted install date/time?
I'm in the process of creating an MSI installer for an old VB6 application we still depend on (yes, I know, upgrade before it dies).
I'm trying to add a backup folder for the user data files in the install-folder (not my application design, nor my application). Unfortunately every user of this application has their own copy of the data file installed on their system (dedicated machines per user), and the installer has the default file. I would like to create a backup folder so that I can manually (if necessary) go back and retrieve previous versions of the file.
What I'm thinking is
c:\program files (x86)\app*.mdb => c:\program files (x86)\app\backups\201804091125
This will be rushed. Please tell me what is not clear.
Custom Action: In order to implement exactly what you describe, you generally need a custom action. This is always unfortunate since they are very error prone: Why is it a good idea to limit the use of custom actions in my WiX / MSI setups?
Alternative?: If you ask me I would install the database in a component of its own, make the file the key file and set the component to permanent and never overwrite if key path exists.
In the WiX source: for the WiX component element, set these attributes: Permanent="yes" NeverOverwrite="yes"). I am not 100% sure what will happen if you do something stupid such as setting REINSTALLMODE="amus" during installation (force overwrite all files regardless of version). It has been a while since I tested the NeverOverwrite flag. But for normal deployment done the regular way the database file should be left alone and not overwritten.
Custom Action Overview: There are properties called Time and Date that are automatically set in the installer, but the Date property will generally contain characters that are illegal in path names. It is possible to just get the properties and replace the illegal characters. However, the date separation characters are probably different based on regional settings and hence hard to predict. Your code could get messy quickly and testing would be challenging (potentially many locales to test depending on distribution scope - a truly globally capable package is challenging).
I would rather get the date and time some other way - via some programming API call where I can determine what format the data comes back in. You also need to run this custom action elevated in deferred mode to ensure it doesn't fall over with access denied (insufficient user rights for operation). This is always quite a bit of clunk to set up and get working. Maybe try the alternative approach first?
I have long considered adding a custom action to abort the install if REINSTALLMODE="amus" has been specified. I would prefer that and the alternative approach described with "never overwrite" to a custom action doing all this copying.
I am writing my first WIX installer. The installed application uses various Microsoft standard OCX controls which are installed as merge modules, for example MSCOMCTL.msm, MSFLXGRD.MSM etc.
For some reason, if the target machine has UAC switched on, running the application after installation fails with a message to the effect that "MSCOMCTL is missing or has not been correctly registered...". However, if the application is run once 'As Administrator' it puts up a UAC "can this app make changes" message (so it's obviously changing something) and then runs fine, and what is more runs forever after without admin privs. (Alternatively, registering the relevant controls with RegSrv works as well).
I have monitored the application with ProcMon and it is obviously doing a late registration. It is as if the installer has advertised the contents of the merge module without installing them. I've also looked at the merge module, and my MSI, with Orca, but I can't work out any way of stopping this behavior.
I did wonder if it was anything to do with the versions of the MSMs, but it seems almost impossible to find out what the latest version of these Microsoft MSMs is, or to find anywhere to download them.
Obviously we do not want to make our customers go through this convoluted process when they install our product. Any suggestions would be greatly appreciated.
Thanks Kiran. We also read that bit in the MSDN documentation. The problem is that we can't alter the Advertise attributes on items that are already built into Microsoft's Merge Modules (well, we could using Orca but it would be messy).
However, I think we may have found the source of the problem. The previous release of our product used a kit built using InstallShield. When we compared the .MSI created by InstallShield to the one created with Wix we noticed that the InstallExecuteSequence table of the IS one contains RegisterProgIdInfo, RegisterClassInfo and RegisterTypeLibraries, which do not appear in the Wix-generated MSI. We think some or all of these may be needed to force the MSMs to install. I need to find out how to put these into Wix, and then to try it to see if it works. I will try to remember to post the result here for posterity.
[Following day] Confirmed. For anyone else who has this problem, you just need to put a <RegisterClassInfo/> tag and a <RegisterProgIdInfo/> tag (and maybe a <RegisterClassLibraries/> tag, but I didn't need one of those) into your <InstallExecuteSequence>.
I am trying to do a custom action at the time of msi installation. But the dll required for my custom action is depends on other dlls. At the time of installtion it is giving the error like "a dll required for this install to complete could not run".How can I load the dependent dll files for this custom action to run properly.
The code that I am using is
<CustomAction Id='CheckingPID' BinaryKey='CheckPID' DllEntry='ValidateKey' />
<Binary Id ='CheckPID' SourceFile='$(sys.CURRENTDIR)\LicenseKeyClient_32d.dll'/>
<Binary Id ='CheckPID2' SourceFile='$(sys.CURRENTDIR)\curllib.dll'/>
<Binary Id ='CheckPID3' SourceFile='$(sys.CURRENTDIR)\libsasl.dll'/>
<Binary Id ='CheckPID4' SourceFile='$(sys.CURRENTDIR)\openldap.dll'/>
The files that you add in binary table usually get extracted with temporary names during the installation, so your DLL will not be able to locate the other DLLs you add next to it.
A workaround is to add those DLLs as normal files in the Temp system folder and delete them when the installation ends. This has the limitation that you need to set your custom action as deferred, so it executes after the files are installed, thus your DLLs get copied to Temp folder.
I don't know if wix has a support for temporary files, similar with the one present in Advanced Installer, but if not you could try to write a custom action to simulate it. Basically what Advanced Installer does is to extract those files in the Temp folder the moment the MSI is launched, and also deletes them when the installation is complete. This has the advantage that you can use the temporary files and in immediate custom actions, i.e. well before the files from your package are installed.
Despite Bogdan's excellent answer, allow me to add my 2 cents:
It looks like you are dealing with some form of license key validation? The best way is generally to deal with your license keys in the application itself, unless you want it written to HKLM instead of HKCU - in which case you might need the temporary admin rights generally acquired during installation.
You can also open a HKLM key for writing during setup, and write it from the application though this is generally frowned upon security-wise. This allows you to write a single license key for all users directly from the application.
The application features more flexibility and control of the process of registering your license key, and crucially an easy way to run the process again. From my perspective this is almost always needed for a serious application - often due to trial versions with the eventual need to register the license key at the end of the trial period from within the application itself - instead of uninstalling the application and reinstalling, or running the setup in repair / maintenance mode - which seems extremely clunky.
I have described this issue previously in some more detail: Reasons to deal with licensing in the application rather than the setup.
I'll also add that WiX DTF .NET custom actions really simplify this problem by allowing you to embed content into the self extracting custom action package and make them available in the current directory at runtime. Very easy.
But yes, Glytzhkof is correct. Any licensing / DRM done inside of an MSI is easily defeated. It's best to do this in the app or both. For example I've worked at companies where it's a share responsibility. You can enter one now or later. I've also worked at companies where the license key had bits embedded in it that drove feature selection. It gets complicated fast so try not to have to go down that road.
The installer I'm writing using WiX 3.0 uses a RegistryValue element to modify an existing registry value (originally written by our main product). I'm trying to figure out a way to restore the registry value when the user uninstalls my utility. I'd like to avoid using a custom action, but that might be the only recourse? TIA.
I did this. The registry value in question was the application associated to a file extension, but it could be any registry value.
My first idea was to use a "custom action" for install and uninstall to preserve
and restore, respectively, the associated regy state. This
seemed simple enough.
I created a setup project in VS2008 and built the CA's as javascript files. The "on install" script grabbed the existing regy value and stashed it into a well-known place. The "on uninstall" script would look in the well-known place, and then put the value found there, back in the original location.
Easy, right?
There were two problems:
the script that ran during install, to preserve the pre-existing registry value,
runs AFTER the registry has already been updated
with the values for the newly installed thing. So it preserved the new setting instead of the setting that was there before the MSI ran. Not useful.
The script that runs during uninstall, runs AFTER the registry values, and in fact the entire directory subtree,
have been deleted. Including the stashed value. So it had lost its state.
To solve that I wrote another script that
re-orders the custom actions so they run at the proper times.
There's actually one more twist. Obviously, the "Restore" script (on
uninstall) won't work if it is run after the registry entries for the app have been deleted. I can't remember now, why... but I also determined that this script could not run before that. Somehow that wasn't working either.
So, I modified the MSI to run the restore script
twice. In phase 1, it transfers the stashed value to a "parking lot" in the registry.
Then the application's Keys and Values in the registry get deleted, but the parking lot remains. In
phase 2, outside the transactional protection, the restore script retrieves the state from the parking lot, restores
the file association, and then deletes the parking lot.
I can't remember exactly why I needed to do this in 2 steps, but I remember fighting with it for a while before coming up with that solution.
The way it works in development:
set the on install and on uninstall CA's in the VS project
build the VS Setup project
run the post-processing script that modifies the MSI.
When using the MSI, it's a little more complicated than I originally thought but it works.
If you are using WiX, you may have more control over the time and ordering of the steps, so may not need that post-processing step.
Finally, you said you wanted to avoid a CA. To me, CA's are avoided because they are painful to produce in C++, and producing them in .NET is often inappropriate. But, it's pretty simple to use Javascript for CA's. Some people think script is the wrong tool for the CA job. I think that's wrongheaded. I think script is a very good tool for this purpose. And once you can accept script as a good tool, then you don't need to hold your nose about creating a custom CA.
The registry table is incapable of writing a registry value during an uninstall so it is correct that this must be done via custom action. I am of the opinion that using script is bad. Whether you choose to listen is up to you. I can tell you that just the other day I was called into to trouble shoot a situation where some wrote a vbscript CA that was failing because the file system object had been unregistered as part of a security lockdown process.
I suggest C++ or C#/DTF depending on your needs.
Faced with similar issue, need to update the registry value on install and restore to previous value on uninstall.
Is the only solution possible is creating a custom action for this purpose?
I found a extension for wix that has fucntions for this purpose
link to wix extensions