I would like to add a FileVersion to a .MSI file.
I do not want to add a Version for the installed product/files. I'm looking for a way to modify the MSI, so I can add something like a .RC header (https://msdn.microsoft.com/en-us/library/aa381058(VS.85).aspx).
It has to remain MSI, I can not change it to an executable.
I can work with... WinAPI? .NET? WiX? ... any hints?
Thanks!
There is no "FileVersion" for a MSI file. There is only a MSI PorductVersion.
The ProductVersion is normal property in an MSI file.
In WiX you find the ProductVersion directly in the project node (see WiX docu).
You can retrieve the information with MSI-Api or COM accessing the properties table. Here a C# sample.
Related
How to replace a strong named DLL in GAC by the windows installer?
I am having two installers that shared some common DLLs from the GAC.
suppose there is any change in any common DLL then
running any one installer with latest DLL is not replacing the existing DLL.
from some old post, it is suggested that changing file assembly version will replace DLL.
that approach is not working. Is there anything else needs to be done apart from that?
Windows Installer will not update an assembly in the GAC if you only change the assembly file version unless your install authoring tool also sets the fileVersion attribute for the assembly in the MsiAssemblyName table of the new MSI.
Aaron Stebner addresses this in his blog posting.
I know that this works when using WiX, as I've done this in several installers. I don't know how this might be done in other authoring tools.
I created a WIX project in Visual Studio 2010 over a year ago. It creates an MSI file and a bootstrapper setup.exe. Actually, it creates that pair of files for two languages - English and French. I am just now integrating this project into our TFS CI builds. I'm having trouble getting the CI build to generate the bootstrapper setup.exe files.
We've recently upgraded Wix on all our build servers to Wix 3.6 RC. So, I thought I'd give Burn a try instead of using the old style of bootstrapper. I added a new Bootstrapper project to my solution. The bootstrapper project includes a simple bundle.wxs that just loads the MSI generated by my old MSI project. However, when I try to build I get the following error:
error LGHT0103: The system cannot find the file
'C:\Tf\Advantage\Dev\Solution\Configuration\LaunchPad.Wix\bin\Release\fr-fr\LaunchPad.msi;C:\Tf\Advantage\Dev\Solution\Configuration\LaunchPad.Wix\bin\Release\en-us\LaunchPad.msi'.
My package reference in the bundle looks like this:
<MsiPackage Id="MyApplication" SourceFile="$(var.LaunchPad.Wix.TargetPath)" />
LaunchPad.Wix is the name of the Wix MSI project. If I change the LaunchPad.Wix project to build only one language then it works fine. It looks to me like the bootstrapper project type just doesn't support building setup files for multiple languages. Is this true? Any suggestions for a workaround?
Edit
Upon further investigation, I wonder if bootstrapper projects even support localization. I tried setting my Wix MSI project to create only fr-fr. The setup.exe that my bootstrapper project created with English. When I edit the project properties for the bootstrapper project the "Cultures to build" field is locked down and blank. How would I build a non-english bootstrapper? Is this possible yet?
There are several things going on here:
If you use multiple Cultures, you can't use TargetPath in something outside MSBuild that expects a single filename. As you found, TargetPath is a list of the localized files that were built. However, you can use TargetPath if you qualify the .msi package's output language: <MsiPackage SourceFile="$(var.TestMsi.en-US.TargetPath)" Id="MsiEnUs" />
If you want to create one bootstrapper that can install either/both en-US and fr-FR, you'll need to list each .msi package separately in its own MsiPackage element.
If you want to create two bootstrappers, one en-US and one fr-FR, you'll need to invoke the bootstrapper .wixproj twice, once for each language. Bootstrappers don't support the Cultures "trick" -- it's problematic to produce two outputs from a single invocation of MSBuild (witness the TargetPath problem).
If you're using WixStandardBootstrapperApplication, it automatically tries to localize the UI based on the user UI language, falling back to the system UI language, and finally falling back to English. It looks for localized strings in directories named after the LCID, so you'd have payloads like this:
<Payload Name="1033\thm.wxl" SourceFile="..." />
<Payload Name="1036\thm.wxl" SourceFile="..." />
Unfortunately, WixStandardBootstrapperApplication strings are currently available only for en-US. That's why an fr-FR bootstrapper shows UI in English. You'd need to localize the WiX source file HyperlinkTheme.wxl or RtfTheme.wxl (depending on which theme you use). Both of these files are in src\ext\BalExtension\wixstdba\Resources.
good. it works as Bob Arnson said.
but you must pay attention to the name and the SourceFile of payload.
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense">
<Payload Name="2052\thm.wxl" SourceFile="2052\thm.wxl" />
</BootstrapperApplicationRef>
if you change the name to another one. the bootstrapper will not be localized.
I'm working on a VS2010 installer for a Windows Service project.
I want to set the [manufacturer] property for the project, but I can't see where it is located in 2010.
When I try to install currently, it converts [manufacturer] to 'Microsoft'.
I can tell from your response to #mrchief's answer that you're looking in the wrong place. The assembly info source file sets the properties for the installed component. But you probably want to change the name on the setup program.
In the Properties window for the Setup project, set the Author and Manufacturer properties.
You should choose the Setup project in the Solution Explorer window and press F4.
Try setting it in AssemblyCompany attribute in your assembly info file
Also, this might help: VS 2010 Setup project: how to get manufacturer name in Programs and Features
I mean doing this in a InstallScript project so the installer would exit in the first place if it's not running with correct processor type.
I found it'll be easy if it's a InstallScript MSI project, just modify the "Template summary" field, while this options is not there in InstallScript project.
I have some requirements which could be met perfectly by InstallScript project type so I cannot git it up.
Thank U in advance for your advices.
In InstallScript you often have to roll your own behavior. In this case, it's easy: just check the SYSINFO struct for the parameters you require, and provide appropriate messaging and abort (or continue). In this case it's probably SYSINFO.bIsWow64.
I'm working on a deployment project (Wix based) which is used to deploy an application to run with AutoCAD and create shortcuts of AutoCAD's acad.exe while passing its own argument.
To achieve this, there is a Custom Action dll (C++) which iterate through Autocad's registry keys and get the "acad.exe" location and create/update the shortcut using MSI Api methods in MyInstaller.msi at run time.
Problem:
On x64 bit OS like Windows 7, Custom Action is reading the proper 'acad.exe' location from registry i.e. C:\Program Files\AutoCAD 2010\acad.exe, and update the shortcut properties in msi at runtime. But when msi finishes creating shortcut, the path is converted to 32bit program files i.e. C:\Program Files (x86)\AutoCAD 2010\acad.exe, which actually doesn't exists.
My Work Around:
As my msi is 32bit (x86), so I created a separate Component with attribute Win64=Yes, and modified Custom Action to update/create shortcuts for this component. But still target path in shortcuts are being converted to C:\Program Files (x86).
I know if I convert my MSI for x64 OS, this might be solved, but at the present, I can't do such a big change.
Is there any way that a 32bit msi can create shortcuts containing paths of x64 OS?
Any help would be really be appreciated..
Thanks a lot.
You are swimming upstream against MSI on this one. (Although I can understand why. )
Officially MSI is never platform nuetral. I assume you are using a custom action to read the registry values because MSI's AppSearch/Reglocator will constrain you to the WoWSys64 node. After that, MSI will substitute even hard coded references to program files as part of an application compatibility approach ( basically microsoft assumes you didn't know what you were doing and that they know what you really meant to do ).
Unofficially- read this thread to find a hack that I figured out to work around this. The summary is I found that if you convert C:\Program Files\ to a short path ( C:\Progra~1 ) that MSI is no smart enough to figure out what you are referring to so it doesn't substitute the value.
http://www.joyofsetup.com/2010/03/27/wix-msbuild-v2-0-and-x64-systems/
Note, this a hack and there is no way of telling if Microsoft will 'fix it' in future releases. The only other approach I can think of is you to then not use the shortcut table and instead write custom actions to create the shortcuts for you.
If you don't want to swim against MSI, consider this workaround. Create a small 64bit EXE ( yes, you can deploy a 64bit or AnyCPU exe to Program Files x86 is a x86 MSI ) that acts as a front end launcher to AutoCAD. Make it query the registry table and find the file then launch it or display a message saying AutoCAD is unavailable if it can't be found.
If you do this you make your install far cleaner.
Ok I was able to solve it:
Problem was, 32bit MSI on 64bit OS, was converting paths (in shortcut table) to 32bit equivalent paths i.e. Our Custom Action dll was getting AutoCAD's path from 64bit registry key as C:\Program Files\AutoCAD 2010\ and then injecting this path to MSI's shortcut table and Directory table. But when MSI was writing the shortcut, it was converting it to C:\Program Files (x86)\AutoCAD 2010.
We can't have 64bit Components in 32bit MSI, but Vice Versa is possible i.e. We can have 32bit Components in 64bit MSI.
However, in my case, I have to use 64bit Components for shortcuts and other components would remain 32bit.
So I have converted my 32bit MSI to 64bit MSI adding Plantform=x64 in Package information. And declare the component as Win64=Yes.
And this solved my problem and now I'm getting proper paths in shortcuts.
Due to this, now I have 2 separate installer i.e. for each 32bit and 64bit respectively.
Best regards
Farrukh