If this is a repeat question, please direct me to the existing solution. I wasn't able to find a matching query.
We currently use InstallShield. I'm attempting to covert a project with 407 files to a WiX3 installation package. I tried using heat.exe to do some of the automation but I get the following warning for almost every file:
c:> heat dir "c:\projectDir\projectA" -gg -ke -template:Product -out "c:\install\projectA\heatOutput"
heat.exe: warning HEAT5150 : Could not harvest data from a file that was expected to be a SelfReg DLL: c:\projectDir\projectA\plugin1.dll. If this file does not support SelfReg you can ignore this warning. Otherwise, this error detail may be helpful to diagnose the failure: Unable to load file: c:\projectDir\projectA\plugin1.dll, error: 126.
Q: Is it normal for this warning to be reported for every file?
If there's a current "How To create/convert to your first WiX install project with many files" tutorial, please point me to it. The key requirement is "with many files".
PS. I know that WiX is designed for incremental install project creation but it would be nice to know if there's an automated way to convert existing install projects.
If there's a current "How To
create/convert to your first WiX
install project with many files"
tutorial, please point me to it. The
key requirement is "with many files"
You can take the msi file generated with installshield, and then decompile it with the dark.exe tool which comes with wix. As you can see in this diagram, dark.exe generates wxs files from a msi file.
You can use it like this:
dark installer.msi decompiled.wxs
See dark /? for more information.
edit: I don't use Votive, but AFAIK it should be able to handle the wxs files generated by dark. Did Votive show you an error?
edit2: wixproj files are just for visual studio and msbuild integration. The core tools don't know or use this format. Simply create a blank wixproj and add the wxs file to it from visual studio.
edit3: You should not compare the size of the wxs file to the msi file size. Like an installshield project file, a wxs does not contain the files to install. It only references them. Your installshield project file is not 70MB large either. If you want to extract the binary files from the MSI, then you should use dark.exe with the -x <path> switch.
Are you trying to extract data from x64 DLL's? That doesn't really work...
Related
I have one wix project file abv.wixproj and its product.wxs. I am able to generate its msi file by building it from Visual studio.
I would like to generate msi file using command (i.e. from .bat file).
I would like to generate msi file using nant. I got some code having <target> tag but not sure, in which file should I add this tag. should I create new file or in wsx file.
Kindly help me to share some example of nant commands to generate msi file using command line without Visual studio build
I have tried using "%WIX%bin\candle" *.wxs -o obj\ but it is giving below error
error CNDL0150 : Undefined preprocessor variable
I need one or more commands that will read wxs file and create msi or exe file by executing wix project
The .wixproj is an MSBuild project file. Just use the msbuild task from NAnt and let the targets files handle all the candle and light details for you.
I migrated my WIX project from V2 to V4 and then changed the namespace in the .WXS files
I replaced the below namespace
<Wix xmlns="http://schemas.microsoft.com/wix/2003/01/wi">
with
<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
Once the changes have been made when i run the build installer i am getting the below error:
error CNDL0199 : The Wix element has an incorrect namespace of
'http://schemas.microsoft.com/wix/2003/01/wi'. Please make the Wix element
look like the following: <Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
E:\Code\EMR\Wix\src\EMR_Registry_entries.wx
I replaced the new namespace but it is not reflecting. Once i run the build installer it is setting with the old namespace. I tried multiple times but it is always setting the old namespace.
Please help me to resolve the issue.
UPDATE: Question that came up from a second read of your question.
Source Control: "Once I run the build installer it is setting with the old namespace." - are you sure the build process doesn't
auto-magically 1) check the WiX source out of your source control system? Or 2) maybe it is doing some XML manipulation via the automation script?
WiX Version: Are you sure you are compiling with WiX 4? Maybe you are compiling with WiX 2 or WiX 3 unintentionally? Try hard coding the full path to the WiX binary in your build system - if you have one. Please see this (Sean is a WiX developer): Migrate Wix Project to version 4.0. Frankly I am not sure how well WiX handles multiple-version installations on the same box combined with migrated sources (identically named binaries of different versions - WiX 2, 3, 4 - globally applicable via the PATH variable? Not sure).
Visual Studio / Cmd.exe?: Are you compiling with Visual Studio or via the command line? (I am not quite sure reading your question). Maybe try via the command line (towards bottom) if you are using Visual Studio - or vice versa. Make sure you use the correct WiX binaries (in other words WiX 4).
Linked Files?: I don't have any WiX 2 sources to migrate, but I am wondering if you have several source files that are interconnected. Was that even possible in WiX 2? I can't remember. In either case, I would make sure you have updated all WiX source files that are pulled in during the build process. Please read the log carefully. Maybe try to compile them with Candle.exe directly using the command line (cmd.exe instead of Visual Studio) to see if the file compiles OK.
Source Files?: If it still does not work, please put the source file online so we can have a peek. Github.com for example. A quick look at the source (the real McCoy) goes a long way sometimes - and sometimes it doesn't help at all. Maybe give it a go. Redacted sources are just fine - encouraged even. Please pay close attention to sensitive data: How do I avoid distributing sensitive information in my MSI by accident? (and this also goes for published source files - obviously - not just the compiled MSI and its helper files - such as silent installation template batch files).
In summary: That became a lot of babble. Maybe first try to compile the migrated WiX source with the right WiX 4 binaries to
determine if that works or not. Then work backwards to figure out what
happens during the build process.
I am trying to make changes to the WixStandardBootstrapperApplication.cpp and generate a dll as per the suggestion from this link. I have downloaded the wix310-debug source and am modifying the file present under wix310-debug\src\ext\BalExtension\wixstdba\ location. There is a wixstdba.vcxproj file under this location which I am trying to open using Visual Studio 2012. Whenever I try to do that I get the error:
Unable to read the project file "wixstdba.vcxproj". The imported project "C:\tools\WixBuild.props" was not found.
I am not sure what should I do to correct this. Also, based on the referenced link, I think I am updating the correct file but let me know if that is not the case. Any help in this would be great. Thanks in advance.
In your vcxproj there's a line like this:
<Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildProjectDirectory), wix.proj))\tools\WixBuild.targets" />
The debug source isn't really the source of wix. It includes all the wix source files but it is not really buildable. This zip has all the built pdbs and is used to debug only.
You want to download the wix source from wixtoolset's github so that you can build wixstdba. But, this is for version 3.10.3 currently and may have some version specific changes but I don't see anything that would be an issue using the dll built here against wix 3.10.2 since the engine and bootstrapper application interfaces should have remained the same.
But, you should be able to build all this with only the WixStdBA project. You will have to copy over the wixstdba folder. Edit the vcxproj and remove the import line mentioned above (it should be near the bottom).
Now, add this project to your a new solution or your installer solution in visual studio. We need to add addition include and library directories. All these include directories will be in your wix install location (default C:\Program Files (x86)\WiX Toolset v3.10) In Properties -> C/C++ -> General -> additional include directories add your wix SDK include path. If you are using visual studio 2013 you can use the full path or you can use "$(WIX)\SDK\vs2013\inc". $(WIX) should reference the WIX environment variable which points to the install directory which is added when installing wix. This should be the better option if you will be building on a build system with wix installed since the location may be different across machines.
Now for addition library directories, we go to the Properties -> Linker -> General -> Additional Library Directoryes and add in the correct lib path. If you are using visual studio 2013 you want to put in $(WIX)\SDK\vs2013\lib\x86. Finally we need to reference the libs that are needed to build the bootstrapper dll. Under Linker -> Input -> Additional Dependencies, add in "dutil.lib;balutil.lib". My additional dependencies has a lot more stuff and I don't remember if it was by default there. Here's my Additional Dependencies in full anyways
dutil.lib;balutil.lib;advapi32.lib;comctl32.lib;comdlg32.lib;gdi32.lib;gdiplus.lib;kernel32.lib;msimg32.lib;odbc32.lib;odbccp32.lib;ole32.lib;oleaut32.lib;shell32.lib;shlwapi.lib;user32.lib;uuid.lib;wininet.lib;winspool.lib;version.lib;%(AdditionalDependencies)
With this you should be able to build the wixstdba project and get a dll built. Without editing any code this should be the exact same as the wix included wixstdba.dll.
You could try referencing this dll instead of the wix included one (have to define your own BootstrapperApplication instead of using the BootstrapperApplicationRef to one of the wix ones) or just drop in this dll into your wix location's bin.
I've just started looking at wix again now that it looks like installer projects are going to be deprecated from VisualStudio. We have a third party application that is "install via xcopy", which makes it hard for us to track in terms of versioning so we'd like to create an msi for it. There are several hundred files that are part of the installation.
I'd like to use heat to create the list of files for the installer, but I've heard that it's not good to use heat to create the wxs file more than once with autoguids because then your installer will have issues.
I was wondering if in wix 3.6, there was a command line parameter to heat which would take a previously generated wxs file as the source for guids? I want heat to autogenerate guids for any new files, but use the previous output of heat as a database for existing files.
If you use the -ag flag this will set the guids to be generated at compile time and as long as the path doesn't change the compiler will keep the same guid for each component. Rather than use a command-line to do the harvesting it is better to edit the *.wixproj file and add a HeatDirectory element.
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.