Two of my library depends on the third. But the latter library must be copied to the system32 directory, another two - to the ProgramFiles directory. PLease could anyone advise on how to deal with registration of the first two libraries. I need to use self-registration. I tried to specify the id of the main library as a companion file, but it did not help. What should I do?
MSI's SelfReg table doesn't support ordering the operation of registrations. You could use the QuietExec custom action to call regsvr32 /s in the right order but I wouldn't do it myself.
The optimal design is to not rely on self reg. Have you thoroughly exhausted using MSI to handle the registration data for you as it was designed to do?
Related
I notice when I use the Class MSI table and other related tables to register COM classes during an MSI install, the LocalServer32 values don't have paths, but rather have some cryptic value. I see limited information on the web, suggesting this may be some sort of hash of the MSI ProductCode and Component GUID, but I can't find detailed information on how this works.
I'm wondering specifically if one of the features of this sort of registration is to ensure, in a multi-instance installation, that the instance of the component returned is from the same installation as the client, where possible. I kind of doubt it, but I want to understand everything this scheme accomplishes, and don't know where to find the information.
Here's a sample of such a registry entry:
It's called a "Darwin Descriptor". It exists to support self-repair on COM activation. That was an interesting idea with horrible execution (endless repair loops with source prompts and ugly basic UI), WiX defaults to writing the raw COM registry keys to avoid it.
I have msi setup that was created in installshield and I am executing the DTF custom action dll as a commit custom action. If I insert MessageBox.Show into the custom action, I can see that there is a temporary folder inside [PROGRAMFILESDIR] called "CustomActionProject.CA.dll-" and there is copied CustomActionProject.CA.dll with all its references.
Is there any way to tell the technology not to create this temp folder and extract+execute the CustomActionProject.CA.dll in the same folder where is .CA.dll located?
Edit:
I found out that I can not include the references in .CA.dll by configuring wix.ca.targets. Which prevents .CA.dll to contain 20MB of dlls in my case.
Now I would like to make sure that CustomActionProject.dll will be able to see the references that are installed with the product.
The files are:
<ProgramFilesFolder>
<MyApplicationFolder>
CustomActionProject.CA.dll
... About 30 dlls installed with the application that CustomActionProject.dll needs to call
<Place I Would Like to See CustomActionProject.dll extracted>
DTF automatically extracts it's files to a temp folder for execution and then cleans up on disposal. This is very good in that it eliminates certain race conditions. You can still author those files into your installer if you like. For example, at a previous company, our installer used several DLL's for license checking during the install and installed them for use by the application at runtime.
BTW, make sure you've seen this:
WiX DTF Behavior Alert
Your custom action was programmed in a managed .Net language (probably C# or VB.Net). As msi files may only contain dll custom actions comprised of native code the DTF tools, specifically the tool makesfxca.exe, packs / wraps the managed dll together with helper code resulting in a self extracting, native code dll. Following WIX´s naming convention the native custom action dll contains an .CA infix.
In order for this (i.e. having custom actions written in languages producing managed code) to work, self extraction has to take place. So the short answer to your question is "No".
I am trying to use heat to create the necessary registry keys. The assembly is a simple dummy Shell Context handler it adds a context menu to a .txt ending.
If I use Regasm to register it then a registry key (not the only one but the one that is different) is added at this. Note that it is at txtfile.
[HKEY_CLASSES_ROOT\txtfile\shellex]
[HKEY_CLASSES_ROOT\txtfile\shellex\ContextMenuHandlers]
[HKEY_CLASSES_ROOT\txtfile\shellex\ContextMenuHandlers\{1e25bcd5-f299-496a-911d-51fb901f7f40}]
#="VBShellExtContextMenuHandler.FileContextMenuExt Class"
If I use heat then this txtfile is not used. It uses .txt
[HKEY_CLASSES_ROOT\.txt\shellex]
[HKEY_CLASSES_ROOT\.txt\shellex\ContextMenuHandlers]
[HKEY_CLASSES_ROOT\.txt\shellex\ContextMenuHandlers\{1e25bcd5-f299-496a-911d-51fb901f7f40}]
#="VBShellExtContextMenuHandler.FileContextMenuExt Class"
The other keys that regasm makes seem to be the same as Heat but this one is not and it means that the menu fails with the Heat keys.
Is this a known problem with heat?
I know I could simply change it but this is a test and I need to add about 15 extensions.
Take a look at a gotcha in the help topic Regasm.exe (Assembly Registration Tool).
Note that the .reg file does not contain any registry updates that can
be made by user-defined register functions. Note that the /regfile
option only emits registry entries for managed classes. This option
does not emit entries for TypeLibIDs or InterfaceIDs.
I'm not 100% certain on Heat's interaction with Regasm but I know InstallShield's .NET Com Interop calls Regasm /regfile so this gotcha would apply.
Personally I only use these tools as one of many tools at my disposal to gather the requirements, sort it all out and then author it by hand.
I have already achieved a custom command without dependence without any problem.
But here it is a custom command that need to be link with four other dll to work.
<Binary Id="libeay32" SourceFile="..\bin\libeay32.dll"/>
<Binary Id="libintl" SourceFile="..\bin\libintl.dll"/>
<Binary Id="libpq" SourceFile="..\bin\libpq.dll"/>
<Binary Id="ssleay32" SourceFile="..\bin\ssleay32.dll"/>
<Binary Id="custom" SourceFile="..\bin\custom_cmd.dll"/>
<CustomAction Id="cc_postgres" BinaryKey="custom" DllEntry="on_postgres_cmd" Execute="immediate" Return="check" HideTarget="no" />
I got the following error at installation
Error 1723. There is a problem with this Windows Installer package. A
DLL required for this install to complete could not be run. Contact
your support personnel or package vendor. Action cc_postgres, entry:
on_postgres_cmd, library: C:\Users\THE\AppData\Local\Temp\MSI17BB.tmp
How doing this spot in Wix, without recompile everything in static.
Thx.
MSI does not provide these services, and WiX does not offer an extension to do so. You could, I suppose, write a WiX extension for this purpose, but why?
MSI runs your Type 1 custom action by first extracting a copy of the Binary resource to a temporary directory, then invoking the entry point in that copy, and (upon completing the custom action) releasing the temporary DLL copy. (Or not: MSI might decide to keep that copy around for a little while, as an optimization in case you're going to call some other entry point later. But that's up to MSI, not to your code.)
The key point is that the Binary resource is auto-loaded temporarily... and only the one resource. That means it is up to your custom action to load any other resources needed.
Your custom action would, as its first steps, need to open a view on the Binary table, read the Data column from the appropriate record as a stream, and dump that data buffer to a file somewhere, then do an explicit ::LoadLibrary(). Then ::GetProcAddress() on the function(s) your custom action will call from that loaded library, and use the fetched pointer(s) to do the explicit call(s). Finally, since you are a courteous programmer, when your custom action is done, it needs to tear all this infrastructure down before returning: release the view and library handles, delete the temporary files, etc.
If all this seems a lot of hassle, you're right, it is. The very simple solution is exactly the one you reject: link your custom_cmd.dll statically. Yes, that will make your binary, and the .msi which contains it, a little bit larger (and not that much larger, since you may no longer need separate Binary copies of the dependent DLLs). But that's pretty much the only downside. The upside is that your custom action carries along with it everything it needs to get its job done.
I routinely do a static link on any binaries -- not just custom actions, but bootstrappers, etc. -- that run at install time, even if they don't have explicit external dependencies. (But of course they have implicit ones, like the Visual C++ runtime libraries, etc.) That way, I not only know I have the resources I need, but the right version of those resources, and not whatever version the customer may have happened to install previously... or not have installed at all.
Your install package is a scout who does not know his environment ahead of time. It might be a big American city... or it might be the Moon. Or Barsoom. Don't presume that you will have cell-phone service... or oxygen. Carry it with you!
I am in the process of creating an MSI for our product. I would like the product to be able to install side-by-side. So that I can install 1.0.0 first and later can add 1.0.1 so that the two versions are both installed.
I am using WiX to create the msi and would like to know how this can and should be done in Wix? For example
Do I need to create new Guids for all components?
How would i add the version info to wix or should i rename my product completely?
How can I create the projects so that releasing a new version requires minimal changes in the wix project?
Greetings,
Martijn
You should be able to get away with just changing the top-level productcode and UpgradeCode GUIDs to make your two products completely unrelated, and use the Productversion to identify the version. You can share component guids between products (that's how merge modules work) so that the guts of your installer (component definitions) needn't be tweaked and can still be shared.
You major challenge will be ensuring that the two decoupled products don't interfere with one another, for example by having the same default installation folder, start menu entries and the same Add/Remove programs entry. You might achieve this by including the product version number in the ProductName Property, which can look a bit techy in your install UI, but it isn't unheard of.
Regarding your first question: No, you don't need to.
But why?
I had difficulties to understand the windows installer rules in my side-by-side scenario.
You really need to understand the concepts of component rules (including when you need to brake them) and key paths. WiX doesn't abstract these aspects away.
This answer does already highlight possible interferences.
Let's consider a few examples.
The GUID of the component with the application executable does not need to be changed. This breaks the component rules, but it works, as both versions of the product define the same component in a non-interfering way.
A resource shared by both versions is not directly supported. A prominent example is the use of file extensions using ProgIDs, as shown here.
If you change the GUID (also happening when using the "*" GUID), the extension will be removed when uninstalling either version.
If you don't change the GUID, the extension will be retained, but point to the version which was installed most recently. You may go with this option as the lesser of two devils, supporting at least a scenario where users uninstall the versions in the same order in which they installed them.
There is a pitfall here: The extension needs to be the key path of the component. This makes the usage of the ProgID element problematic in a side-by-side scenario as you'll get the ICE69 warning in case you don't put the ProgID element in the same component as the referenced file. Further more, it's an implementation detail of WiX which registry entry it generates will be the key path.