Don Walker wrote
>
> Here is the situation:
>
> 1. We allow multiple versions of our product to be installed at the same
> time if they have a different Major.Minor version. I don't believe that
> the MajorUpgrade element supports this option. The UpgradeVersion elements
Rob Mensching-7 wrote
>
> Or use MajorUpgrade element.
>
I don't think that the MajorUpgrade element gives me the flexibility that I
need. My assumptions (and what I believe to be best practice) are:
1. The UpgradeCode is fixed for all versions of the product.
2. The Product Id is set to "*"
Chad Petersen wrote
>
> I was able to get past this error in your example by adding this inside
> the Fragment
>
>
>
>
>
Scheduling RemoveExistingProducts worked for me too. Ironically, I had just
finished reading about scheduling it in the Windows Installer help and was
considering
In WiX version 3.6.3109.0 I am getting the following build error:
Product.wxs(16,0): error LGHT0094: Unresolved reference to symbol
'WixAction:InstallExecuteSequence/RemoveExistingProducts' in section
'Product:*'.
The same error appears for line 18.
My test example follows:
http://schemas.mic
Aha! I ran the test using an XP image running in VMware Player with VMware
Tools installed. It looks like there was some sort of conflict between the
merge module and VMware when repairing.
As discussed previously in this topic, using the redistributable solved the
problem simply and appears to be
FWIW I created a Release config for wixstdba by copying the Debug config and
then making obvious changes like removing _DEBUG and DEBUG symbols and
turning on optimization. It appears to work fine with the limited testing I
did.
--
View this message in context:
http://windows-installer-xml-wix-to
Rob, your response inspired me to modify wixstdba to add the logging feature
I wanted. I was able to do this and removed the need for custom actions in
my MSI's and forcing all my XP users to upgrade to Windows Installer 4.5.
I've posted the code change to wixstdba below for comments and criticism.
On Jun 28, 2012; 1:17pm Rob Mensching-7 wrote:
/1. The "resuming" error message on Repair sounds like a bug. Can you make
sure you are on a very recent build of WiX v3.6 (things were fixed around
that area recently) and if that still happens, open a bug./
I've logged bug 3538817.
/2. " I get the
Rob Mensching-7 wrote
>
> The wixstdba isn't designed to show the internal MSI UI. You'll probably
> want to make a custom BA that is designed to show the internal MSI UI.
>
Could you provide more detail about this? My simple test case sets
DisplayInternalUI="yes" for my MSI package that is bas
Rob Mensching-7 wrote
>
> IIRC, there were bugs in WinSxS on Windows XP that did not handle
> replacing
> files in use well causing more reboots than necessary. Yay, Fusion!
>
I've replaced the VC90CRTx86 merge module with a bundle that runs the C++
redistributable. This works on XP without any
This section of the log is the first occurrence of the string "reboot". I
also tried verbose logging (/l*v) and didn't get any earlier occurrences of
"reboot". I've uploaded the entire verbose log through nabble. See
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/file/n7579097/Setup
I have a fairly simple test install built with WiX 3.6.3025.0. It does include
the VC90CRTx86 merge module. On Windows 7 I can install and then immediately
repair the install without being asked to reboot after the repair. On Windows
XP I get asked to reboot after the repair. Here is the part of
I was aware that "The mba (Managed Bootstrapper Application) can install the
.NET
Framework *before* your managed BA comes up. That's actually howthe WiX
toolset works. Install it on a machine with out .NET Framework and it will
first install .NET Framework then launch the custom BA. " There is
res
I've submitted feature request #3535563.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Extracting-embedded-packages-from-the-standard-bootstrapper-tp7578806p7578880.html
Sent from the wix-users mailing list archive at Nabble.com.
-
In reply to Rob's points:
1. I knew about the Burn log file Variables and link on the failure page.
Since I'm new to both Windows Installer and WiX, I was hoping to avoid the
need to write my own bootstrapper just to control logging. I may be
installing to XP machines without .Net installed so I w
I've found a number of topics about log file location and some topics about
logging detail levels by searching the mail list and the bug tracker. I still
don't know how to get logging working the way I want so here we go again.
The Windows Installer properties that interact with logging are
Msi
dark can be used as described. However, my customers don't have WiX installed
and may not have .Net - I am under the impression that dark uses .Net. What
I'm looking for is to give them a single file. If they want access to the
embedded packages I would like to be able to tell them to just run the
Thanks for letting me know that WiX will work well with Windows Installer 3.1
and there are no current plans to change this. Now all I have to decide is
whether I need features from Windows Installer 4.5 for my custom actions.
Would you care to speculate if you ever plan to require a newer version
If I do need to provide my customers access to the embedded msi files from a
bootstrapper I would like to be able to extract them instead of needing to
provide them separately. The standard bootstrapper comes close to being able to
do this with the /layout command line parameter - it works great
I'm likely to be supporting installs on Windows XP until past the MS end of
support date. Most of our customers running XP most likely have Windows
Installer 3.1 installed. As far as I can tell, upgrading to Windows Installer
4.5 will force a reboot. Should I require Windows 4.5 anyway?
I have
Peter, thanks for your reply. I'm a developer, not an IT guy, so please
excuse me if the following questions are too basic. I wasn't aware that you
could install software remotely using login scripts. Are these the same as
startup scripts? See
http://www.mombu.com/microsoft/windows-group-policy/t-d
We are investigating replacing InstallShield InstallScript-based installs with
Windows Installer-based installs. Many of our installs have prerequisites like
.Net and some also chain several installers. In the absence of any external
demands I would implement the basic installs as msi files and
22 matches
Mail list logo
