How to provide publisher Name for MSI installer which is developed using WIX Installer?
While installing my .msi installer it's showing unknown publisher, how to provide a name for publisher?Is it possible to do this within WIX? If so kindly help me how to implement this using WIX installer.
I think you are looking to avoid the security warning that is displayed when someone installs your setup. For this you would need to sign the setup with your certificate and a private key. You can try to do this by following the steps explained in the following links:
How to Digitally Sign Microsoft Files
Signing .MSI and .EXE files
Everything you need to know about Authenticode Code Signing
Assuming you are looking for a publisher name in the control panel Programs and Features. You could use the Manufacturer attribute in your Product tag.
<Product Id="PUT-YOUR-GUID"
Manufacturer="PublisherName"
Name="ProductName"
UpgradeCode="PUT-YOUR-GUID"
Version="1.0.0">
Using WiX's in-built tool insignia is fairly straight-forward. Here's the steps to do code-sign a WiX MSI:
Add signtool to my PATH. It is commonly found in C:\Program Files (x86)\Windows Kits\10\bin\x64 or, more recently, C:\Program Files (x86)\Windows Kits\10\App Certification Kit
Add insignia to my PATH. Your WiX Toolset directory is commonly found at
"C:\Program Files (x86)\WiX Toolset v3.10\bin"
Sign my MSI in a post-build event (MSI Project -> Properties -> Build Events) by calling this:
signtool sign /f "c:\certificates\mycert.pfx" /p cert-password /d "Your Installer Label" /t http://timestamp.verisign.com/scripts/timstamp.dll /v $(TargetFileName)
Further notes and thoughts:
I have also signed the application (I think) by just doing Project Properties -> Signing and enabling click-once manifests, selecting
the certificate and checking the Sign the assembly option.
Here's my similar answer on how to do the same but for a bootstrap bundle: using insignia to sign WiX MSI and bootstrap bundle
Related
I am using wix toolset to create MSI build.
Here is the Binary source in Product.wxs file.
<Binary Id="BI.CA"
SourceFile="..\..\CustomAction\bin\$(var.Configuration)\CustomAction.CA.dll" />
MSI generated and works as expected in local but fails in build machine showing below error.
Could not find CustomAction.CA.dll
I see that CustomAction.CA.dll is present in the build machine but not the path which I specified.
How do I embed this dll in to MSI?
Update
In build machine, I see the DLL here
E:\BuildAgent\1\b\CustomAction.CA.dll"
When your DLL has the name CustomAction.CA.dll that should not be! Then you need to double the CA here <Binary Id="BI.CA"
SourceFile="..\..\CustomAction\bin\$(var.Configuration)\CustomAction.CA.CA.dll" />
The CA is an internal postfix for the DLL but the output / target of your Custom Action Library should not have it in the name.
You have two options:
a) Remove the CA from the output target in Custom Action project
b) Introduce a second CA in MSI-Project Binary Element
See also How to execute a WiX custom action DLL file with dependencies
I've got a 32b MSI installer developed on 64b machine using WiX toolset (3.10).
It has been tested on both 32b and 64b platforms with different Windows (7, 8.1, 10) and it works without any issues.
The problem starts when I've tried to install my MSI via Microsoft Intune. (It works well with other tools for mass deployment)
While performing the fresh install, user is prompted to insert MSI file (after it is selected, the installation goes smoothly but that is not the purpose of mass deployment).
I've observed that the problem is not occurring when I remove from MSI files that are harvested using heat tool.
The command is (passed via Visual Studio):
"$(WIX)\bin\heat.exe" dir "C:\SOURCE_PATH" -ke -scom -frag -srd -ag
-var var.Resources -cg ResourcesGroupId -dr INSTALLDIR_RES
-out "$(ProjectDir)Source\Fragments\HarvestedResources.wxs"
This component group is added to main Feature containing all other components.
The destination directory is created as:
<DirectoryRef Id='INSTALLDIR_RES'>
<Component Id='cmp_ResDiR' Guid='{SOME_GUID}'>
<CreateFolder />
<RemoveFolder Id='INSTALLDIR_RES' On='uninstall' />
</Component>
</DirectoryRef>
INSTALLDIR_RES is a sibling path located under INSTALLDIR.
Logs are showing that ComponentRegistry is done with exit code 1 (success).
Install scope is per-machine, elevated installation is enabled. All properties used during install are marked as:
secure="yes" admin="yes"
And visible under AdminProperties and SecureCustomProperties (checked via Orca). I don't use any CustomAction to deploy this resources, though.
How can Intune affect my MSI? What am I missing?
The problem was only partially related to MS Intune and absolutely not related to heat.exe and harvesting files.
It turned out that there were two issues:
MSI was deployed using MS Intune but without providing the original MSI to the users. During installation the MSI has been copied to the temp directory and removed after app has been installed. It would be ok, although access to original MSI is helpful in case of self-repair, which leads to second issue:
On some machines, during initial run, the MSI was launching the self-repair procedure. As the original MSI wasn't available on hard disk, the user was prompted for selecting the MSI manually as described in first post. Thanks to the great description of self-healing issues in MSI by Stein Åsmul I was able to detect the root cause (advertised shortcut to main executable with regEntry in user specific path) and fix it.
As a summary: MS Intune doesn't affect deploying files harvested by heat.exe.
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
I've been trying to sign an MSI file in a post build event with the following code
signtool sign /t http://timestamp.verisign.com/scripts/timestamp.dll /f "E:\Products\Tools\DigitalId\Certificate.pfx" /p 1501ocbc /d "Server" "E:\Products\Setup\Server_Setup\ServerSetup\bin\Release\en-US\ServerSetup.msi"
This will sign OK with the Visual Studio command prompt and similar code works for C++ projects. However, when building the setup and signing the code with post build events, I get a code error, 9009. After much debugging I have come to the conclusion that WiX is using the ordinary command prompt. How do I get cmd.exe in WiX to open with Visual Studio tools?
Or is there another way to sign my packages?
You could define the event like this:
"%programw6432%\microsoft sdks\windows\v7.1\bin\signtool.exe" sign /t etc..
Note: you need to adapt the path to your install (program files, Windows SDK version, etc.), or you could also define your own environment variable.
It looks like there is a built-in way of signing MSI files which seems to work correctly with SignTool: Insignia.
Register the certificate and use the /sha1 hashkey - just to be sure the certificate is good (check browser-internetoptions/content/certificate)
SignTool path - make it explicit as Simon Mourier suggested or put signtool.exe in an accesible path
Choosing postbuild operation - you should sign the MSI file after you've completed all operations upon the MSI file. Any action upon the MSI (INSERT/UPDATE Property) will undo the signing.
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...