and i need to register a dll . Right now am registering the dll as below
<CustomAction Id='comReg' Directory='INSTALLLOCATION' Impersonate='no' Execute='deferred'
ExeCommand='"[NETFRAMEWORK40CLIENTINSTALLROOTDIR]regasm.exe" "[INSTALLLOCATION]myProduct.dll" /codebase' Return='check' />
but all are suggesting to use HEAT.exe in internet wherever and whenever i surf . I even have gone through this link. But there they have only the syntax etc. I really dont know how to work with it just by knowing those syntax.
I need some step by step procedure or some good blog which elaborately tell how how to harvest a dll and how to impllement it in to wix code and how the registry will be done , so that i can register my dll based on conditions also.Even i tried this link alse
Regards
Registering a COM component is done through standard Windows Installer actions and tables. Numerous table entries are required so WiX provides heat.exe to harvest COM files. It works by inspecting a file for type libraries and, if the DllRegisterServer entry point is present, running it in a Registry sandbox where changes are intercepted and captured. (In the era of Windows Installer [1999-present], DllRegisterServer is effectively deprecated for any other purpose.)
As you may know, a Feature is the smallest user-selectable unit of installation. A Component is a member of one or Features in one or more Products. Heat creates a component for each file it harvests and a ComponenentGroup for each harvest run. So, you have to pick a ComponentGroup Id and reference it in one or more Features. You also have to pick a Directory Id for the destination of the ComponentGroup.
Now, it is simply a matter of editing your project file to harvest the file. To edit a project file you could use a text editor but Visual Studio is all set up for it. See How to: Edit Project Files.
Add a HarvestFile element to a new or existing ItemGroup, entering the desired ComponentGroup Id and Directory Id
<ItemGroup>
<HarvestFile Include="comserver.dll">
<ComponentGroupName>COM</ComponentGroupName>
<DirectoryRefId>ServerDir</DirectoryRefId>
</HarvestFile>
</ItemGroup>
In your Product.wxs or elsewhere, add a ComponentGroupRef to one or more Features.
Related
I created a solution with two new projects: ATLProject1 which is a COM dll and ATLProject2 which is a COM EXE. To both projects added same simple class with single method.
Added both to WIX setup project (this is an existing setup project that already installs other COM dlls. I'm just using it for this test).
Added following lines to product.wxs:
<Component Id="ATLProject1.dll" Guid="{...}">
<File Id="ATLProject1.dll" Name="ATLProject1.dll" KeyPath="yes" SelfRegCost="0" Source="$(var.TargetDir)\ATLProject1.dll" />
</Component>
<Component Id="ATLProject2.exe" Guid="{...}">
<File Id="ATLProject2.exe" Name="ATLProject2.exe" KeyPath="yes" SelfRegCost="0" Source="$(var.TargetDir)\ATLProject2.exe" />
</Component>
and also
<ComponentRef Id="ATLProject1.dll" />
<ComponentRef Id="ATLProject2.exe" />
The file also has these lines:
<EnsureTable Id="PublishComponent"/>
<EnsureTable Id="Condition"/>
<EnsureTable Id="TypeLib"/>
<EnsureTable Id="Class"/>
<EnsureTable Id="Extension"/>
When running the setup I get error: "Module ATLProject2.exe failed to register. HRESULT -2147024769" (hex 0x8007007f the specified procedure cannot be found).
If I remove ATLProject2 from setup, it succeeds and ATLProject1 is correctly registered in registry (this is without generating registry information e.g. using heat, it just works).
Should exe component be treated differently?
I found this 10 year old post suggesting heat.exe does not treat COM exe as COM. If this is the problem, Not sure if this is still the case?
The Windows Installer does not recommend using SelfReg to register at install time. Instead, adding the registration to your .wxs code or capturing the registration at build time is highly recommended.
To add the registration manually, you don't use EnsureTable, you use the COM related elements (like Class, ProgId, TypeLib). It can be tedious but will be far more robust than trying to selfreg during installation.
Unfortunately, the alternative to capture the registration during build using heat.exe (provided in the WiX toolset) does not support capturing from executables. If you are open to a commercial solution, we (FireGiant) developed an alternative to heat.exe that can capture executable registration (and much more). That advanced harvesting solution has more documentation on the FireGiant site.
RegServer Switch: COM EXE files are normally self-registered via the /RegServer switch as in:
MyBinary.exe /RegServer
In other words EXE files are not registered via the normal regsvr32.exe mechanism. This is the tool used to register COM dll's and OCX files, but it does not handle EXE files. There is also an /UnRegServer switch to unregister EXE COM files - for the executables that support /RegServer (which is not all COM EXE files - it could be missing as a feature).
Self-Registration: Self-Registration is not ideal to register COM files, and here is a write-up of why this is the case: MSI register dll - Self-Registration considered harmful. In MSI one extracts the COM registry data and populates a number of special COM-tables to allow the registration of the COM server in a way that supports advanced features such as rollback. I don't like the COM extract either (risk of self-repair problems, more on self-repair problems), but it helps in most cases - especially when there are dependencies that can trigger registration problems. Moreover it is the way COM files are supposed to be registered in MSI. It is the standard. I should note that some COM settings go into the Registry table still - since there are no dedicated COM-related tables for them.
heat.exe: WiX's own heat.exe tool now can extract COM data from dll files and ocx files (32-bit). But it does not seem to work for EXE COM files - I am not sure why:
heat.exe file MyCOMDll.dll -out MyCOMDll.wxs
RegSpy2.exe: There is a tool you can use to extract COM registration information from both DLL, OCX and EXE files. It can be downloaded from here: http://www.installsite.org/files/iswi/RegSpy2.zip. Here is the main page listing numerous tools. The RegSpy tool is written by Phil Wilson - MSI Expert and author of The Definitive Guide to Windows Installer (APress).
Here is how to extract the COM data from a COM executable (if you get no data, try unregistering the file first and then running regspy.exe):
RegSpy.exe MyBinary.exe /RegServer >> RegistryOutput.reg
The exported *.reg file can then be converted to WiX elements. This is not an easy process. Using the WiX tool heat.exe does not populate the proper COM tables, but rather puts everything in the Registry table (which will work though, barring MSI validation errors):
heat.exe reg MyCOMRegistryData.reg -out MyWiXFile.wxs -sfrag -suid
There used to be a tool called Tallow that converted reg files to WiX COM registration, but this tool is no longer anywhere to be found. I am not aware of any other ways to generate it short of writing it yourself, or download another deployment tool and import the COM data or extract it and decompile the generated MSI with dark.exe and take out the WiX markup. Or figure out how heat.exe writes its WiX XML output with COM data and adapt that to process the output from RegSpy.exe.
UPDATE: Throwing in a link to Paraffin: https://github.com/Wintellect/Paraffin. This is supposedly a "better Tallow". I am not sure what it supports in terms of COM-extract. My quick test seemed to indicate it doesn't support COM extraction at all, but supports auto-generating WiX markup and add and remove files for updates.
Custom Actions: It is possible to register your COM EXE by means of a custom action that calls the /RegServer switch as well, though this is not recommended for all the reasons listed in the link above (self-registration considered harmful).
Some Links:
Adding a .reg file to registry WIX
How to generate WiX XML from a .reg file?
I am new to WIX. I have created an installer to create web site on IIS.I need to use this website installer inside two more wix project. e.g in another project I am creating window service and want create website as well in same project and in another project I want to create database and this website as well.
You can put shared functionality inside a wixlib project.
You basically put shared functionality into <Fragment> tags and use a <ElementRef> tag to include the fragments in your main wix project.
You probably already use the WixUIExtension which looks like it's basically just a wrapper around the ui.wixlib. You incorporate part of the ui wixlib when you do <UIRef Id="WixUI_InstallDir> and then everything in the fragment of WixUI_Installdir.wxs is merged into your main wix project at compile time. (I think the preprocessor does this)
So if you can identify portions of your installer that are shared between your multiple installers, you can make a wix lib that includes multiple InstallComponent.wxs and a way to reference them into your main install. Generally this can be with UIRef, RegistrySearchRef, or in the case where there is no real Ref element you can use, just include a description property at the top of your Fragment something like
<Property Id="ComponentNameInclude" />
then in your installer project you can reference this property to bring in everything in the fragment this property belongs to.
<PropertyRef Id="ComponentNameInclude" />
I would suggest reading through the wix source (I linked the github to one of the files) to get a better idea of how wix itself makes use of some wixlibs.
I need to include a dll/exe in the resulting MSI (created through a WiX project), but I do not want to deploy them during installation: I only want to use them in some CustomAction my purpose is to include an existing exe/dll and call it during installation from wxs code (not from a CustomAction dll).
Is it possible to include files which are not deployed during installation? I mean, only pack them inside the resulting MSI, and call them for some task while they are unpacked inside %temp% folder?
Also, it would be nice if somebody could show some sample code of how to include dll/exe through the Product.wxs XML code unit.
Thanks.
Yes, include them using the Binary element.
<Binary Id='MyCustomActionBinary'
SourceFile='$(var.CustomActionProject.TargetPath)' />
This will make them available to your CustomAction where you can use the BinaryKey attribute to reference the Binary:
<CustomAction Id='MyCustomAction'
BinaryKey='MyCustomActionBinary'
DllEntry='MyCustomFunction'
Execute='deferred' />
If you are using C#/DTF to write a custom action, you simply add the DLL's as references. For any other kind of file you add them to the project as Content | CopyAlways and the build will automatically include these files in the self extracting custom action. They will be available in the current directory ( a temp directory) when the CA runs and automatically cleaned up when the CA ends.
My installer has to copy files into installdir... My application has around 2000 files and it is not possible for me to write the script to add each and every file to the installer.
Is there any option in wix so that I can add all the files or the entire folder consisting the files at once? I am new to wix and i didnt find any option in any tutorial for this... Please do assist me and thanks in advance.....
Heat is the WiX harvest tool. You can run it on a directory to generate the necessary WiX source code.
EDIT:
If you want to run heat before your VS project builds, add it to your project prebuild events as seen in the screenshot below (this is how I have my project setup to dynamically generate WiX source for our ever changing help content):
Note the -var wix.HelpSource switch that I have. The WiX source files generated by heat will set the location of the source files to that variable instead of hard-coding it. So the generated source will have components that look something like this:
<Component Id="Welcome.htm" Directory="Content" Guid="INSERT-GUID-HERE">
<File Id="Welcome.htm" KeyPath="yes" Source="!(wix.HelpSource)\Content\Welcome.htm" />
</Component>
And in my particular case, I define that variable on the Tool Settings screen of my WiX VS project to the relative directory ..\..\Help\Output as seen below:
NOTE: Harvesting files in this manner will cause the GUIDs of the components harvested to change every time you build. If you don't want your GUIDs to change, you may have to write some wrapper that calls heat to harvest the files, then updates your original WiX source, leaving all the GUIDs alone.
I'm using Visual Studio to build my wix file. So far I have one file Product.wxs and it's working for a simple install.
Now I want to add some custom dialogs. I think from the two articles below, I understand how to do it - after I get my environment set up:
http://blog.torresdal.net/2008/10/24/WiXAndDTFUsingACustomActionToListAvailableWebSitesOnIIS.aspx
and
http://www.merlinia.com/mdt/WiXTutorial2.msl
I downloaded the source, and I see 35 *.wxs file in this directory
wix35-sources.zip\src\ext\UIExtension\wixlib
This is where I'm starting to get lost.
Do I need to copy some (only the ones I want to change) or all these files to my Visual Studio Project. Until now, I have been running with none of these source files.
How does my Product.wxs know to use these files? Does it look at local directory first? Or do I have to rebuild some C# modules?
I included these lines in my Product.wxs, and it gave me the user interface at execution time:
<UIRef Id="WixUI_Mondo" />
<UIRef Id="WixUI_ErrorProgressText" />
Thanks,
Neal
Do I need to copy some (only the ones I want to change) or all these files to
my VisualStudio Project. Until now, I have been running with none of these source files.
Since you are already using WixUI_Mondo, I assume you want to customize that UI. Locate WixUI_Mondo.wxs in the wix sources, and copy that to your visual studio project. Rename the file to WixUI_MyCustomUI.wxs and change the UI Id attribute inside the file to Id="WixUI_MyCustomUI". You don't need to copy any other files yet; the dialogs referenced in the copied UI sequence are compiled into the wix tools as resources, so wix "knows" these dialogs by name.
In your product.wxs file, change the UI reference to <UIRef Id="WixUI_MyCustomUI" />. If you now rebuild your setup, the UI should still look exactly as WixUI_Mondo as we haven't customized anything yet.
If that worked, you'll probably want to customize or add a dialog. Again, you can start from an existing dialog by copying it from the wix sources. You'll also have to edit the WixUI_MyCustomUI.wxs file so that it uses your new dialog. Take a look at this other answer I wrote for an example.
How does my Product.wxs know to use
these files? Does it look at local
directory first? Or do I have to
rebuild some C# modules?
You do not have rebuild any C# modules. The only reason you downloaded the wix sources is because the existing UI sequences and dialogs are good examples to start from. In principle you could also ignore the wix sources and write these wxs files for the UI sequence and dialog definitions from scratch.
When you use the command line tools, you combine multiple wxs files by simply passing multiple file arguments and they will be compiled and linked together. If you use wix with visual studio, you just have to add the wxs file to the project. A non-trivial wix setup will typically be defined by many wxs files.
The content of a wxs file can container references to elements in other wxs files through elements such as UIRef, ComponentRef, ComponentGroupRef, DirectoryRef etcetera.