Open wixbot opened 15 years ago
wixbot
commented
12 years ago Equally useful would be an MSBuild variable for the currently-building culture that we could reference in our .wixproj files. With such a variable, we would be able to include a different EULA for each language, and generate transforms with Torch from the built MSIs.
wixbot
commented
12 years ago I gave up, re-think, and tried to create another configuration "Release-ja-jp". Defined preprocessor variable Culture=ja-jp. This seems to work mostly. One thing still missing is I can't pass this to bootstrapper MSBuild task. As alastairs said, MSBuild variable would be the right place to put culture in. I'm still looking into if there were any better way.
wixbot
commented
12 years ago I'm new to WiX, and figured out that it's not just easy to do localizations in WiX.
wixbot
commented
10 years ago Originally changed by
barnsonReleaseset tov3.x
One handy use of project references is to package a "client" installer inside a "server" installer. When the sever and client have localized installations, $(var.ClientProject.TargetPath) points to the parent folder, but multiple targets are being generated, each installed in a sub-folder named after the culture it was built with.
My ideal solution would be that $(var..TargetPath) would include culture being built and resolve to the MSI file in the appropriate sub-folder.
If changing how TargetPath resolves is not acceptable, the next best solution would be a new variable that resolves as described.
Another possibility could be a new variable for the culture being compiled. The reference would read something like this, where CultureBeingCompiled is a new preprocessor variable: $(var.ClientProject.TargetDir)$(var.CultureBeingCompiled)\ClientInstall.msi
bq. Originally opened by @hurcane@ from "http://sourceforge.net/p/wix/feature-requests/473/":http://sourceforge.net/p/wix/feature-requests/473/