I have generated an MSI using Wix for the deployment we used octopus. While running the msi build through octopus some files like dlls, .. are not getting updated in the respective path for the first time of deployment. If we install the same for second time then works fine all the files placed in the folder.
These are the steps I have followed:
I have created a Wix project and generated a msi build through that. Then through the octopus using .xml file I have deployed the content in the specified folder. And deployment was not successful through octopus.
You really haven't given any information to troubleshoot. Are you using major upgrades or minor upgrades? What's your command line? Have you logged the installers and read through the logs? What do they tell you?
msiexec /i example.msi /qn /l*v install.log
/qn = silent /l*v = verbose logging
My first suspect is that you aren't versioning your DLL's correctly and that Windows Installer is skipping over them. Please see:
File Versioning Rules
Default File Versioning
Replacing Existing Files
Related
I have a log file that is written to the installation directory by the MSI. This log file contains code I've written to help with troubleshooting installation issues within the MSI package. The bootstrapper also has its own automatic log file. Is there a way for me to set my MSI to log to the same file as the bootstrapper?
Why do I want to do this?
If an install fails, the bootstrapper displays an error screen with a link to the bootstrapper's log file. This is the information my clients send me when they have problems during installation, but this information is useless to me. I'd love it if this log could also capture all of my MSI troubleshooting information.
You can get the path of yout bootstrapper file and store it in a variable , then when u executing the msi file
"/c msiexec /i Blabla.msi /L*v bootstrapperLogFilePath"
i am using the following command to see the logs in wix installer.
msiexec /i "D:\WixProjects\DFServicesWixSetup\DFServices\bin\Debug\DFServices.msi" /L*V "D:\DFServices.log"
but this command is trying to install the msi again.
I want to execute this command from wix after finishing the installation and log file need to save in installed folder.
can any one help me on this.
You need to decide in advance if you want Windows Installer to make a log file. You also need to decide in advance where it should go. If you want it to end up in the install folder then you either need to copy it there after installation or specify the install folder in advance, too.
In Windows Installer folders are controlled by properties. You can specify such properties in the command that starts installation. The name of the property for the "install folder" depends on how the installer authoring; INSTALLFOLDER is one typical name.
So, you could do this with a command like this:
msiexec /i "D:\WixProjects\DFServicesWixSetup\DFServices\bin\Debug\DFServices.msi" /L*V "D:\path\DFServices.log" /qb INSTALLFOLDER="D:\path"
The /qb switch is reduce the UI such that the user is offered the chance to change the installer folder. It may more may not be need for your installer, depending on what dialogs its UI normally shows.
So, the first step is to figure out which property sets the install folder in your installer.
We are using WiX to sign and create MSI files and then bundle them into a signed EXE file. The MSIs are generated fine.
Each MSI file contains a command to run at the end to kill the application. In the standard WiX manner, we use CAQuietExec to run a quiet command (we've no Form, so we can't use CloseApplication).
This works just fine for the signed MSI files and also works fine if the MSI file is bundled into an unsigned EXE file.
However, if we sign the EXE, then the signature appears OK, but the kill command causes a 1603 Error Code.
We eventually (by literally commenting out each line in the MSI WXS file, building and running the EXE) isolated the issue to the CAQuietExec line that executes a 'taskkill' command.
Is there a way we can get more information on this? It doesn't make much sense and ensures we can't deploy a bundled EXE file.
I managed to find the problem. We found :
1) .Net 45 rather than .Net4 wouldn't have the issue (i.e. changign the pre-req and out app requirement)
2) The signing should be carried out in Wix
3) Sign all contents AND the MSIs too
I have an MSI that setups my application. It has a single component and installs only to %PROGRAMFILES% (no shared binaries). Simplified, it looks like this
Msi file, Monday build:
Program.exe (v1.0.0)
ThirdPartyLibrary.dll (v2.0.1)
Now, if I discover a bug in the program caused by my upgrade of the ThirdPartyLibrary dll from v2.0.0 to v2.0.1, and thus revert the reference to v2.0.0, it seems my MSI doesn't automatically replace the file in the installation directory?
Msi file, Tuesday build:
Program.exe (v1.0.0)
ThirdPartyLibrary.dll (v2.0) <- downgraded
What is the best practice here to ensure that the program folder always contains exactly the binaries in my setup? Should I a) wipe everything from the setup directory before copying the new files? Is there an option (in Wix) I can use that makes the msi force an overwrite of all files regardless of version?
What if I remove a file from the setup (a file that would cause errors if present at runtime), then the only way to have a working program after the setup, would be if it deleted all files first?
You can use a msi trick. In the File table in the msi database edit the Version column and enter a higher version, 3.0 for example. This way you will take advantage of the file versioning rules.
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...