Dear Wix Users,
I'm working on the feature selection GUI of a custom (managed) BA. When
running for installation, I need to determine which features of each
package in the bundle should be installed by default: unless I'm missing
something, this depends on comparing the INSTALLLEVEL property of
Huh. So, with the upgrade codes being identical, shouldn't it be able to
find and install over the old product? Why would it be failing in that case?
On Mon, Jul 14, 2014 at 5:46 PM, Phil Wilson phildgwil...@gmail.com wrote:
The values of UpgradeCode in the Properties tables are the actual
Hello Everyone,
I thought this would be a trivial condition, but I can't seem to find a
winning combination.
I have a text control that is located in my WelcomeDlg, I want to display a
message to the user when the installation is being ran on Server 2008 or
Server 2012. In all other
the wxs file is an xml file, is yours valid xml?
why not use CDATA on the second condition also?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-Show-Hide-a-Text-Control-on-Server-Installation-tp7595834p7595835.html
Sent from the
Hello,
Thanks for the response.
I use CDDATA in both conditions, I should have pasted that in the sample I
pasted... I apologize for being unclear. As for the compiler returning the
error, it was a type-o on my part.
Condition Action=show![CDATA[VersionNT = 601]]/Condition
Condition
Classification: Public
This is what I use to check for Server 2008 R2, Server 2012, Server 2012 R2:
![CDATA[Installed OR ((VersionNT = v6.1 AND ServicePackLevel = 1 AND
NTProductType = 3) OR (VersionNT = v6.2 AND NTProductType = 3) OR (VersionNT
= v6.3 AND NTProductType = 3))]]
Ste ve
aha, you said it did not work with so..
check this?
http://robmensching.com/blog/posts/2008/11/3/how-to-determine-if-you-are-installing-on-windows-client/
VersionNT64 should be 601 for both server2008r2 and windows 7x64 (but not
set(undefined) on Windows 7, 32bit)
--
View this message in
Hello,
Thanks for the responses...
I am guessing that MsiNTProductType and NTProductType are the same ... :-)
Thanks NTProductType is what I was missing.
In case anyone In the future is looking for documentation:
http://msdn.microsoft.com/en-us/library/aa370329(v=vs.85).aspx
Marc
Sorry for the double post.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-Show-Hide-a-Text-Control-on-Server-Installation-tp7595834p7595841.html
Sent from the wix-users mailing list archive at Nabble.com.
This blog should help:
http://robmensching.com/blog/posts/2008/11/3/how-to-determine-if-you-are-installing-on-windows-client/
--
View this message in context:
Is there a possible way to load the theme content based on certatin condition
in a specific page. I have a install page with text content displaying the
details of application being installed along with pre-requisites that are
needed for the application. If the pre-requisites is already installed
I assume you are using WixStdBA and not a custom one of your own. Today it
doesn't allow for this, though I did do a quick proof of concept a while back
(https://github.com/jchoover/wix3/compare/WIXFEAT4149). If you're not scared of
building your own BA, you could try cherry picking my change
The approach that I used, (some time ago before I switched to using a mba),
is (as I recall)
1) Define a string variable in your Bundle and make it overridable-'yes'.
Variable Name='svWelcomeMessage' Value='some default text' Type='string'
bal:Overridable='yes'/
2) In the localization file
Hello everyone,
I'm wondering if it is possible to have an existing product that was
installed using a Visual Studio Setup Project be migrated so that the MSI
is part of a Burn bundle and the upgrade process does not involve
RemoveExistingProducts.
The new Burn bundle contains many of the
Your new MSI should be able to remove the old MSI if you get the upgrade
information correct. That will use REmoveExistingProducts. Not clear why you
want to avoid that.
___
FireGiant | Dedicated support for the WiX toolset |
When you manage feature states, you need to manage all feature states. Thus the
defaults aren't terribly relevant, thus INSTALLLEVEL can for all intents and
purposes be ignored.
___
FireGiant | Dedicated support for the WiX toolset
I have been able to remove the old MSI but as part of the uninstall for the
original MSI, some data stored in ProgramData is removed, as well as some
data files that are stored in the actual Applications folder.
The goal was to try to make the upgrade process as smooth as possible. I
originally
Hi Rob,
Thanks for the comment. I understand that I'd need to manage all feature
states, but isn't that precisely why I'd need to know whether each feature
should be installed by default or not? Surely without knowing INSTALLLEVEL,
I must assume that all features should by default be installed,
I'm testing some different installation/upgrading scenarios and I've found
that if I try to uninstall a bundle from Add/Remove Programs that during the
Burn UI I get prompted to locate either the Burn exe file the bundle was
created from itself, or one of the packages if the package is not
What version of WiX were you using? Was the Bundle/@UpgradeCode the same
between the two bundles? What does the log file look like when just starting
the uninstall? Was your upgrade a full upgrade, or did you do a patch bundle?
-Original Message-
From: barthooper
The upgrade is an uninstall of the old product, using the VS setup, so
if it's true that the VS setup is removing files when it uninstalls
then there really isn't much you can do. That uninstall will do what
it does, and it looks like it makes no differentiation between being
uninstalled and being
WiX Version 3.8.1128.0 with the same Bundle/@UpgradeCode on both of the
bundles.
Relevant log details:
Prompt for source of container: WixAttachedContainer, path:
C:\Users\User\Desktop\WiXBootstrapper.exe
[0F80:0634][2014-07-15T16:22:12]e054: Failed to resolve source for file:
The upgradecode values need to be identical AND the new MSI needs
entries in the Upgrade table, however you populated that with your
WiX. The codes can be identical but without entries in the Upgrade
table in your new MSI that target the upgrade code values of the
products you wish to upgrade,
23 matches
Mail list logo
