No, definitely not. The security issues have been discussed here in the past.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: Jiri Tomek [mailto:katu...@volny.cz]
Sent:
Hello,
is it possible to add new packages to Burn install chain dynamically from
managed BA if these packages were not known during build time? What I'm
trying to achieve is to ship a small bootstrapper to users and let this
bootstrapper contact my server and get list of packages to install. This
Hi
I am still new to wix and am having trouble working out how I can do this, if
anyone could point me in the right direction I would be very grateful!
I am building a custom installer using wix wpf and would like my users to enter
in a firewall port, creating the UI has not been a problem and
Hi,
I'm trying to package the .Net 4.5.2 redistributable into my burn application,
by following the instructions in the documentation.
(http://wixtoolset.org/documentation/manual/v3/howtos/redistributables_and_install_checks/install_dotnet.html)
But it fails to find the .Net installer in the
Classification: Public
Try this
?define NetFx452MinRelease = 379893 ?
Chain
PackageGroupRef Id=Netfx452Full/
!-- Check for .NET 4.52 --
WixVariable Id=WixMbaPrereqPackageId Value=Netfx452Full /
util:RegistrySearchRef Id=NETFRAMEWORK45/
PackageGroup Id=Netfx452Full
Hi All,
I have created a bootstrapper which support different languages during
installation. So I have added the language files from bundle as mentioned below
PayloadGroup Id=Localization
Payload Name=Localization\LGG\CustomBA\CustomBA.de
Hi,
this issue?
http://wixtoolset.org/issues/4382/
On 3/12/2014 12:53 AM, Georg von Kries wrote:
I too thought I saw a feature request for files in use in WixStdBa but I
cannot find it anymore. Maybe it was on the mailing list only.
I am willing to contribute this feature for the WixStdBa.
Rather than trying to do something that is not supported for security
reasons, take a look at using the support for RelatedBundle and the Addon or
Upgrade Actions, which allow you to ship a bundle and then later create
another 'Addon' bundle (with new packages, or in the case of the Upgrade
Action
Why do you need a new UpgradeCode all the time?
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: Griesshammer, Christoph (GE Healthcare)
The scenario that I have is that once used downloads bootstrapper it will
serve as central point for installing future updates, new packages etc. From
what you described I will have to always create new bundle with new packages
and then let original BS download it via some kind of autoupdate that
How do I auto-gen an UpgradeCode? * isn't a valid entry for UpgradeCode. Do I
actually need the build process to go in and build a new code?
Christoph
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Tuesday, May 26, 2015 1:06 PM
To: General discussion
As I had described in my other emails, I am in a situation where our upgrades
are really just an install of another version. They need to exist side-by-side.
But I need to remove the warning that is brought up that I don't have an
upgrade code, and the upgrade code can't have the * value.
Yes, I read that. However, that doesn't say why you need a unique UpgradeCode
all the time.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: Griesshammer, Christoph (GE
Having the same UpgradeCode for 2 installers causes the installer to initiate
an upgrade instead of an additional installation. I want a new UpgradeCode each
build, so that no 2 packages will have the same UpgradeCode, allowing us to
install the multiple versions. If there is a better way to do
Yes, always update the Bundle. It vouches for the security of everything it
contains (hopefully, you sign your bundle).
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From:
Thank you for the answer John!
An additional question:
What attributes do I need to include for the MajorUpgrade element? I looked at
the documentation and it isn't immediately clear to me.
I want to still allow multiple versions of the product to be installed. They'll
have the same GUIDs,
Despite its name, UpgradeCode can serve other very useful purposes... like
detection.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: David Connet
We have most definitely considered that. But then comes the next issue. In
order to make those changes, we need to make application changes. But we can't
do that because the other team is so busy still fixing other defects and adding
new features, that we can hardly coordinate enough time to
Provide the UpgradeCode and suppress upgrades in the MajorUpgrade element.
--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise
Notification Service
Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050
|jocoo...@jackhenry.com
So in your cleanup efforts, why not cut ties with the old versions completely?
Put it in a new and unique folder, and handle the common files. I don't know
if any of them use COM, the GAC, or if you have access or the ability to
request a rebuild of the application. For COM, I'd suggest
Why would you want to intentionally sabotage yourself? Provide an UpgradeCode,
and just don't release any upgrades.
-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: Tuesday, May 26, 2015 10:33 AM
To: General discussion about the WiX toolset.
Subject: Re:
I'm understanding now that I can use the MajorUpgrade element while providing a
UpgradeCode to achieve what I need. I'm just not sure from the documentation
yet.
What attributes do I need to include for the MajorUpgrade element? I looked at
the documentation and it isn't immediately clear to
The component (child) package can't add referrence to its main package
(parent).I have a component package that can be included in differents main
packages and when I make this package I don't know the possible packages that
could be include it.As this component package is released by a company
Nevermind. I realized my big mistake here is that if you don't specify the
MajorUpgrade tag, then you don't have any upgrade support. I was writing the
documentation incorrectly, and was under the false impression that by
specifying the UpgradeCode you automatically allow the standard upgrade
This statement is not true:
Having the same UpgradeCode for 2 installers causes the installer to initiate
an upgrade instead of an additional installation.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
You can see my latest email. I thought about that after I emailed it, and
tested it out. I realize now you need the MajorUpgrade element for it to work.
Thank you for your help (everyone who responded),
Christoph
-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com]
Sent:
Yeah, ships passing in the night. smile/
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Griesshammer, Christoph (GE Healthcare)
I think that there may be different ways to approach RelatedBundle. I can
only share the approach that I have been using. For every bundle I create I
assign a relatedBundleGuid (which is different than the UpgradeCode for
that bundle), along with a BundleTag:
RelatedBundle Action='Detect'
Hey everyone,
I have a feature ‘Foo’ with default InstallLevel=0. In the Condition table, I
set Foo’s InstallLevel=1 if “VersionNT=601 And MsiNTProductType=1”.
- During a normal install, the Condition table will be processed and Foo will
have its InstallLevel=1.
- During an administrative
https://msdn.microsoft.com/en-us/library/aa367541%28v=vs.85%29.aspx says
During an administrative installation, the installer creates a source image for
all features in the product except those feature with 0 in the Level column of
the Feature table.
Hi there,
I have a question about the following piece of Wix code. I am finding that all
components added by the following foreach loop has the same GUID. Is there a
way to guarantee a unique and stable GUID for each competent and still use the
foreach loop?
?foreach INST in
File the bug. Burn (the engine) should never crash.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: Uni Gauldoth [mailto:unigauld...@gmail.com]
Sent: Tuesday, May 26, 2015
Don't add a MajorUpgrade element.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: Griesshammer, Christoph (GE Healthcare)
[mailto:christoph.griessham...@ge.com]
Sent:
I am WELL aware of the following:
1) You should always have an upgrade code, even if you don't plan on
upgrading. But for this specific product, I am positive I do not want the
upgrade code. We will never support an upgrade for this product, due to other
incredibly obnoxious
Hi,
I've found the culprit.
I installed a program named Lingoes(a translator), and run the Ligoes.exe
in the back.
When my installer starts, it loaded the following dll before entering
stub.exe's wWinMain.
C:\Users\Administrator\AppData\Local\Lingoes\Translator\lingoes-us\OpenText32.dll
It looks
I am getting the following error for my project:
The Product/@UpgradeCode attribute was not found; it is strongly recommended to
ensure that this product can be upgraded.
I am WELL aware of the following:
1) You should always have an upgrade code, even if you don't plan on
upgrading. But
Jacob,
I'm already sabotaged. The scenario is:
Another team developed an InstallShield package for an msi, and a Wise package
for an exe. The packages didn't even match in what they were delivering (a
headache in itself). They didn't follow the installer rules. What they did, was
deliver to a
To say that you don't' have time to do it right because the other team is too
busy fixing bugs and adding features is planning to fail. If the application is
using and deploying custom COM objects, reg-free is the only way you are going
to be able to support multiple versions on the same
There we go. Thanks Bob :)
On May 26, 2015, at 10:34 AM, Bob Arnson b...@firegiant.com wrote:
https://msdn.microsoft.com/en-us/library/aa367541%28v=vs.85%29.aspx says
During an administrative installation, the installer creates a source image
for all features in the product except those
39 matches
Mail list logo
