No solution to the repair and uninstall MSI UI yet. Non-trivial problem. If
there isn't a feature request tracking it, you might open one so then you can
track its progress (or lack thereof).
___
FireGiant | Dedicated support for
Cool! Sounds a lot like this:
http://robmensching.com/blog/posts/2008/10/10/what-are-.wixlibs-and-why-would-you-use-them/
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original
IIRC, 0001 errors are internal errors and provide a stack trace to help track
down where better error message should be added.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original
Something doesn't compute there. Can you be a bit more specific about what
upgrade in step 2 means? Also, does OnDetectRelatedPackage provide useful info?
___
FireGiant | Dedicated support for the WiX toolset |
that answer the question?
It seems DetectRelatedPackage does not fire, and neither does
DetectRelatedBundle (The log covered the entire detect phase). I'll do some
more tests and see if that could be related.
Best regards,
Carl
-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com
Yeah, rebuildAll.cmd should probably be removed. Dead code I expect.
If you want to build, msbuild from the root of the source code.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original
IExpress was deprecated a long time ago (security issues, etc). You might
consider using a Bundle instead.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: krupesh
You could make your BA run on NETX v4.5 and carry NETFX v4.5.2 in your Bundle.
Thus if the user has NETFX v4.5 then v4.5.2 gets installed as just part of your
Bundle.
___
FireGiant | Dedicated support for the WiX toolset |
IIRC, RemotePayload does not provide all the metadata necessary to represent an
MsiPackage/MspPackage.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Andrey
Maybe this will help?
https://support.firegiant.com/entries/24408043-Debug-service-start-failures-
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Gábor Zoltán
Are you building a solution? Solution variables are only available when
building a .sln.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From:
feature and people won't need to write some classes to parse and store
these values.
3 Ok.
01.08.2014, 08:49, Rob Mensching r...@firegiant.com:
1. Sounds like you want support instance transforms. There is a feature
request for that.
2. The BA is provided
Winterop.dll is a 32-bit so your calling assemblies need to stay 32-bit not get
JIT'd to 64-bit.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From:
There is a feature request open for Burn to support multiple instances.
-Original Message-
From: serkbugs [mailto:serkb...@yandex.ru]
Sent: Thursday, July 31, 2014 01:51
To: wix-users@lists.sourceforge.net
Cc: Sergey Kozhemyachenko
Subject: [WiX-users] Multiple Instance installations
Not supported today would be a good feature request.
-Original Message-
From: Taylor, Duane E. [mailto:tay...@mitre.org]
Sent: Thursday, July 31, 2014 10:02
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] database script file execution can't find needed embedded
support files
I had.
31.07.2014, 21:28, Rob Mensching r...@firegiant.com:
There is a feature request open for Burn to support multiple instances.
-Original Message-
From: serkbugs [mailto:serkb...@yandex.ru]
Sent: Thursday, July 31, 2014 01:51
To: wix-users@lists.sourceforge.net
Cc: Sergey
/update/remove process by myself
throught setting RequstedState in OnPlanPackageBegin event but it didn't affect
Execute(parameter from logs) and it didn't run my msi. I want some methods in
Engine/BA to force some things to happen.
01.08.2014, 02:13, Rob Mensching r...@firegiant.com:
What
I don't see anything obvious. Debugger is probably required.
-Original Message-
From: linos [mailto:lino...@hotmail.com]
Sent: Thursday, July 31, 2014 20:09
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Passing Variables from C# custom BA to WIX
Hi Rob,
Thank You for the
Don't use variables. Process the PlanPackageBegin event and tell the engine the
state of the package.
-Original Message-
From: linos [mailto:lino...@hotmail.com]
Sent: Wednesday, July 30, 2014 13:24
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Passing Variables from C#
Looks right. I'd check to see that your WixVariable is in the referenced code.
-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: Wednesday, July 30, 2014 13:27
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WixVariable and 'custom' bind variables
I
Does it work with v3.9? Does it work after restarting the machine?
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Nick Ramirez [mailto:nickra...@hotmail.com]
To be clear, it's not a question whether WiX supports it. It's a question
whether the Windows Installer supports it. Did you try setting the hotkey in a
static control with tab order before the edit box. That's the way you typically
handle it in Win32 dialog boxes.
I wouldn't search. Just include Y in two different Components in B and ensure
the Guid for the Y Component in B matches the Guid for the Y Component in A and
give the Y Component to N a different Guid.
___
FireGiant | Dedicated
Sounds like a bug. Burn should allow you to set that value if it's going to be
required by Windows. Is that requirement written down somewhere? If so, it'd be
great to link to it in the bug.
___
FireGiant | Dedicated support for the
Extend the firewall custom action to support it?
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: John Mellor [mailto:jmel...@blackberry.com]
Sent: Thursday, July
by the BA).
Thanks,
Tom
On 15 July 2014 16:31, Rob Mensching r...@firegiant.com wrote:
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
. smile/
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com]
Sent: Wednesday, July 16, 2014 3:54 PM
To: General discussion about
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
Copyright for all of WiX toolset is held by the Outercurve Foundation via an
assignment agreement. Details here:
http://wixtoolset.org/development/assignment-agreement/
___
FireGiant | Dedicated support for the WiX toolset |
Probably not but it would be awesome if someone helped add that support.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Phill Hogland
I'd guess Windows Update.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: John Zavidniak [mailto:jo...@windward.net]
Sent: Tuesday, July 8, 2014 9:05 AM
To:
1. No. Custom BA, FTW.
2. Very dependent on what is slow. Investigate your verbose .log.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Nicolás Alvarez
You skipped the important stuff. Like rollback, upgrade, uninstall and
reference counting. Calling regasm will not help you solve any of the hard
problems around those situations. It'll be easy to get clean install running
but everything else is much harder.
At FireGiant, we always recommend
Install Engineer - ESA
Jack Henry Associates, Inc.®
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com
-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com]
Sent: Thursday, July 3, 2014 11:44 AM
To: General discussion about
That's the documented way to sign.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Brian Enderle [mailto:bria...@gmail.com]
Sent: Friday, June 27, 2014 5:12 AM
No.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Anton Iermolenko [mailto:aiermole...@iopracticeware.com]
Sent: Wednesday, June 25, 2014 7:02 AM
To: General
That C:\c45145141abc stuff is from a really lame bootstrapper from MSFT. Burn
never does that. Burn uses the Temp folder and a secure location called the
package cache.
___
FireGiant | Dedicated support for the WiX toolset |
I expect you're breaking the update rules:
http://robmensching.com/blog/posts/2007/1/4/doing-a-small-update-or-minor-upgrade-in-msi-use/
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
And DTF wraps it for you.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com]
Sent: Wednesday, June 25, 2014 10:21 AM
To:
It's possible using Upgrade element.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Steve-Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, June 23, 2014
Seems like a reasonable thing to open a bug against Insignia to handle better,
if possible.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Peter Prikryl
Can you try WiX v3.9 and if it still repros, please open a bug.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
--
HPCC
I'll be uploading the triage meetings to YouTube soon
(https://www.youtube.com/channel/UCVJeW1mjSujNPfsCQhsg7qQ) where we discuss
this issue.
It came down to the fact that what you are doing is very unusual. Since it's so
unusual, you should manage the GUID manually. It certainly isn't a
SourceFile is consistently used throughout the WiX toolset as the location
to the source on your build machine where the bits that need to be included in
the resulting package need to be found. IIRC, the only place where
SourceFile is not used to mean a build machine path is on the File
Not implemented yet. There are discussions how best to implement this feature
in a supportable way.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Alasdair King
it as encoded in
ASCII, UTF-8 or Windows ANSI. If it uses characters from the top half of
Windows ANSI then it's not UTF-8.
-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com]
Sent: Friday, June 13, 2014 8:53 AM
I always get this mixed up but I thought that ASCII
Did fallback not help?
http://wixtoolset.org/documentation/manual/v3/howtos/ui_and_localization/specifying_cultures_to_build.html
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original
That sounds a lot like:
In addition to Melt.exe supporting an input of a merge module and an output of
a WiX source file, I added a new mode: inputs of the .msi and its matching
.wixpdb files and as output, the directory where the .msi contents are
extracted and a new .wixpdb that's a copy of
Melt? http://www.joyofsetup.com/2013/07/16/easy-pure-wix-patching-with-melt/
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Tunney, Stephen
Why? These are internal implementation details to the WiX toolset. If you want
to spelunk the internal file format you would be best served using the API out
of wix.dll.
___
FireGiant | Dedicated support for the WiX toolset |
I always get this mixed up but I thought that ASCII was basically a subset of
ANSI and UTF-8 and they all look the same (unless you write a BOM) until you
use non-ASCII characters. The grand majority of internal WiX goo is ASCII
without a BOM so it all looks the same...
I think Joel agrees
Use a loc variable instead. Wxl files are not preprocessed.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: TimM [mailto:timmay...@smarttech.com]
Sent: Thursday,
Have you seen http://wixtoolset.org/development/?
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: TimM [mailto:timmay...@smarttech.com]
Sent: Thursday, June 5,
tailoring of the MSI package and manipulation of the feature
tree, but you really really don't want to do this :-)
On Wed, May 28, 2014 at 5:29 PM, Rob Mensching [hidden
email]http://user/SendEmail.jtp?type=nodenode=7594938i=0
wrote:
IIRC, I don't think that's going to work out well. You
-to-be replaced InstallShield project).
Any one know if I turn up the logging on MSBuild if I can see each
project's dependency 'tree' as MSBuild see it?
On Wed, May 28, 2014 at 6:19 PM, Rob Mensching r...@firegiant.com wrote:
Sounds a lot like:
http://blogs.msdn.com/b/msbuild/archive/2010/12/21
Yes.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: victorwhiskey [mailto:victorhwhis...@yahoo.com]
Sent: Thursday, May 29, 2014 1:34 PM
To:
Schedule RemoveExistingProducts very very early?
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Jesper Alf Dam [mailto:j...@medical-insight.com]
Sent: Monday,
Sounds a lot like:
http://blogs.msdn.com/b/msbuild/archive/2010/12/21/incorrect-solution-build-ordering-when-using-msbuild-exe.aspx
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original
IIRC, I don't think that's going to work out well. You can try but I think
patching across directory moves probably doesn't work out great since IIRC
moving Component directories during repair doesn't tend to work out real well
either. But that's just from memory...
I think C# projects do the same thing.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: Friday, May 23, 2014 8:20
/
-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com]
Sent: Wednesday, May 21, 2014 3:55 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] [WiX-devs] Query- Wix 3.5 integration with VS 2013
And that technically isn't necessary. You'll just get a warning saying
And that technically isn't necessary. You'll just get a warning saying the
RegistryKey/@Action attribute is deprecated.
I too am curious why upgrading is a big deal. We work hard to maintain
backwards compatibility in the minor version updates.
No. Burn provides a very strong security statement for the contained packages.
If you add packages, you'll want to update the bundle to include them in the
chain or include the additional packages in a related bundle and launch them in
succession.
Is your MSI per-machine?
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: Thursday, April 10, 2014 4:21 PM
To:
the burn chain
Thanks Rob. Is there a work around to achieve this?
-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com]
Sent: Thursday, April 10, 2014 11:34 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain
-
From: gowri.malas...@non.agilent.com [mailto:gowri.malas...@non.agilent.com]
Sent: Friday, April 11, 2014 11:54 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain
Got it. Thank you Rob.
-Original Message-
From: Rob Mensching
That should work. Best guess: Check that the Fragment(s) with the MergeXxx
elements are referenced.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: TimM
Of course, a custom BA could deem this scenario an error condition. Wixstdba
just doesn't.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Hoover, Jacob
1. WiX v4.0 uses .NETFX v4
2. WiX v3.x uses NETFX v4 or NETFX v2 if you don't have NETFX v4 installed.
3. WiX v3.x needs to keep running on NETFX v2.
___
FireGiant | Dedicated support for the WiX toolset |
A custom BA can do anything. The wixstdba probes for .wxl files based on user
local.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Arthur, Christopher
Yes.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Saravan1109 [mailto:biggodannau...@gmail.com]
Sent: Monday, April 7, 2014 3:17 AM
To:
IIRC, there is a feature request open to support this.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Jerome [mailto:jero2r...@gmail.com]
Sent: Monday, April 7,
This? http://msdn.microsoft.com/en-us/library/aa368012(v=vs.85).aspx
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Walter Dexter [mailto:wfdex...@gmail.com]
Should be installed when you install the WiX toolset. If you go to Help -
About do you see the WiX toolset in the list of installed stuff in the listbox
there?
___
FireGiant | Dedicated support for the WiX toolset |
Sounds like something is awry with your MSI. I would expect that to work.
Verbose log file should show you what's going on.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original
IIRC, Windows Installer doesn't let you change the install location of files as
part of a Maintenance Mode. I thought I read that as some fine print in MSI SDK
but always hard to find the data later... of course, my memory could be off as
well.
That data is very squirrely. It depends whether you're getting straight MSI or
MSI interpreted Restart Manager callbacks. It's basically described in the MSI
SDK how the different messages send back different data... although, IIRC, the
documentation isn't terribly clear. Anyway, the data is
a repair, and both times it says Updating Visual
Studio 2013 Registry
-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com]
Sent: Friday, April 4, 2014 11:34 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Visual Studio 2013
Should be installed when you
WiX doesn't, it just builds MSIs. Windows Installer (aka: MSI) does.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: James McConville
No. By design no. The Bundle makes a lot of security guarantees and does not
use external files to define the chain.
A custom BA could use external data (like a .config file) to decide what
packages to install from a chain, but the chain definition is built into the
Bundle.
Yes, there is a tremendous amount of trust between a Bundle and it's payloads.
The Bundle knows a lot about its payloads and does quite a bit to make sure bad
guys don't slip bad stuff in there to usurp your customers. It does mean that
changes to 1 or more payloads typically means updating the
start /wait bundle.exe
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Shane Corbin [mailto:shane_cor...@selinc.com]
Sent: Tuesday, April 1, 2014 11:47 AM
To:
Probably. I trust start more than cmd to not mess with the ERRORLEVEL, that's
all.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Shane Corbin
Easy. Handle the resolve source callback. Your BA gets to make all the
decisions.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: robert_ort...@agilent.com
I'd use a common .wixlib just like the WiX toolset does. See:
src\Setup\CommonLib
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Sean Farrow
Kill the parent and you'll have no more issues with the children. smile/
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Suryadeep Biswal
It actually sounds like stuff that should be part the installation transaction
of a package so that it is properly rolledback/removed/etc.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
That just runs MsiZap in the end and leaves your machine in a dirty state. I
always told my testers that if they came to me with a installation bug after
running MsiZap to format the machine and try again. I didn't like hunting the
voodoo bugs that came from dealing with a machine that had
First guess is that you aren't signing the bundle properly. See the signing
documentation around insignia.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: jonks
Mark the Variable and Property both Hidden and they should not be logged.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Kevin Spence [mailto:kspe...@gmail.com]
1. Probably a DWORD's worth.
2. I'd say, don't create Bundles 300 MB. Windows is slow to verify/launch big
executables.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
Windows Installer uninstalls MSI packages in passive mode so UI is not
displayed.
Ever get the feeling like you're not supposed to show UI during the uninstall
of an MSI? Yeah, me too. wink/
___
FireGiant | Dedicated support for
That's not an MSI. That's a bootstrapper. That's why (I think it was) Jacob
suggested using a Bundle. Then you get full control over the UI.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
Maybe cached MSI?
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Levi Wilson [mailto:l...@leviwilson.com]
Sent: Wednesday, March 19, 2014 9:46 PM
To: General
It's all on me. There have been a lot of behind the scene changes going on that
needed to be completed to get new builds up. There also haven't been many
changes.
However, a new build will happen very soon. Only one or two small behind the
scenes stuff to finish up.
-Original Message-
1. Yes. You can handle disk switching in the source resolution callback from
the engine.
2. Use same UpgradeCode for upgrading Bundles and make sure newer versions have
higher versions.
3. Yes, via the various Execute callbacks.
4. You can definitely read the Variable that contains the log
The latter.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Felix Ulber [mailto:fe...@0x1-software.com]
Sent: Friday, March 14, 2014 10:02 AM
To:
No.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Tobias S [mailto:tobias.s1...@gmail.com]
Sent: Thursday, March 13, 2014 1:39 AM
To: General discussion for
Burn persisting variables can be used instead of using the Remember Property as
long as all your entry points go through Burn. If you need your properties to
be populated during a repair of the MSI directly or patch (which is a repair in
the end) that isn't executed from the Bundle first then
301 - 400 of 5072 matches
Mail list logo
