Hi,
I tried replacing the * with the UpgradeCode Guid.
Still the same errors... I must say the erros seem to be related to the fact
that the patch.wxs has nothing to do with the build diff.wixmst generated from
the 2 winxobj...
Anyway I have products installed at customers already with the * in
The product code and the upgrade code are 2 different things. Don't mix them
up.
You can get the product code from the property table of the original MSI.
Just open it in Orca or InstEd.
The * means generate me a guid at build time - it isn't actually stored as
a *.
-Original Message-
If you generate a verbose log for each patch application, you'll be able to
see which parts are taking more time.
-Original Message-
From: Wang, Miaohsi [mailto:miaohsi.w...@invensys.com]
Sent: 23 January 2012 19:53
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Our WiX patch
I invoked MSBuild with the build project command from within the VS2010 IDE.
To try and check if we've missed signing anything I added overrides of the
SignXXX targets into our project file. In the overrides, I added
WriteLinesToFile tasks to dump out the @(SignXXX) item groups. I didn't get
Hi,
I have a bundle installer that installs several MSIs, but the bundle itself
does not register itself as a separate product in ARP. I have created a
bundle with the latest build (2520), then I installed it. Then I tried to
uninstall it the ususal way: I uninstalled the components one by one.
Hello Mathew,
I am not sure about the custom action and what will be its execute sequence
and all. Can you give some example in code? That will be more helpful.
-
Regards,
Ravi
--
View this message in context:
Hi,
I am using ALLUSER radiobutton control in my installer but there seems some
problem with the UI response. I am using following code for this:
Property Id=PERUSERScur/Property
Control Id=BothScopes Type=RadioButtonGroup X=25 Y=165
Width=330 Height=120 Property=PERUSERS
RadioButtonGroup
Yea, I got that, Thanks.
What I meant was that I can use the same Guid for the Product ID and the
UpgradeCode as the example do.
That way I won't have to open the MSI with ORCA and find the generated Product
ID Guid.
But anyway, it doesn't help :(
I really don't understand the problem...
I take
I am wondering, what is the recommended way to bundle my .msi file with the
Windows Installer 4.5 redistributable and the .NET 4.0 framework using the WIX
3.5 toolset.
I have currently added a GenerateBootstrapper/ section to my .wixproj file:
GenerateBootstrapper
The more I am looking into this it seems more like a new feature to me. I
have found this in the reference documentation, under Bundle:
DisableModify
http://wix.sourceforge.net/manual-wix3/wix_xsd_simple_type_yesnobuttontype.htm
Determines
whether the bundle can be modified via the Programs and
Hi,
2012/1/24 Bob Arnson b...@joyofsetup.com:
On 23-Jan-12 10:17, Dirk Kuypers wrote:
I am just facing a similar problem like described in the ticket above.
See http://www.joyofsetup.com/2010/10/09/experimental-results-part-ii/.
thanks for the link Bob. So the fix should be default with
One more thing I remembered, in our MSIs we don't use CAB, we just create a
folder next to the MSI, it's easier for us to replace/fix text/config files
after a build was already create...
Does this influence the patch.wxs? I see that there is a Media tag that points
to a cab file...
Did you override the targets *after* Import Project=$(WixTargetsPath) /
(I'm just saying because this caught me out.)
Pete
From: scott.lang...@appsense.com
To: wix-users@lists.sourceforge.net
Date: Tue, 24 Jan 2012 10:11:19 +
Subject: Re:
That would invalidate the MSI if you don't keep the relevant tables up to
date too. Its not a recommended practice - do a proper build instead.
I've not built a patch targeting an unpacked MSI but I believe the media
number would still need to be higher than the highest file id in the MSI file
Hi, yes I did.
(This has caught me out in the past too... but I took care this time)
-Scott
-Original Message-
From: Peter Hull [mailto:peterhul...@hotmail.com]
Sent: 24 January 2012 13:01
To: WiX Users
Subject: Re: [WiX-users] When install exe built with burn, UAC dialog says
Unknown
I see, the other reason we don't compress into cab is time, since we compress
everything into RARs for client delivery... so a cab will be redundant. But
point taken, I won't let anyone change a thing :).
To the main problem... I still can't seem to be able to run the Pyro command no
matter
I don't think your problems are related to patch building. I think your
second MSI is not a valid minor update.
Try running the second MSI as an upgrade of the first one using the command
line mentioned in Rob's blog
http://robmensching.com/blog/posts/2007/1/4/Doing-a-small-update-or-minor-upg
I want to run an installed app after setup completes. I've seen the How to...
on the subject, but that doesn't seem to allow for passing command line
arguments to the app, which I need to do. How can I run the app with command
line arguments? (My installer creates a shortcut, with the required
It may take some manual coding but this should give you some hints:
http://gallery.technet.microsoft.com/scriptcenter/4a4a6e09-8031-4a3e-b081-1d
7cbb9cde9c
as long as you have permissions you can use the management stuff to fire up
the MSI on remote machines.
Just make sure the remote machine has
Hello.
I have a small but a very vital question: how to patch bundle? I mean, let
say I have some bundle of 1.0 version with few products inside of 1.0 version
as well. If I just install patches for products themselves they will be of
1.1 version and if I launch bundle it will detect downgrade,
Have you tried using the built in WIX action of WixCA? You can set a property
with the command you wish to run and then schedule it later. From the WIX Help.
Quiet Execution Custom Action
The QtExec custom action allows you to run an arbitrary command line in an
MSI-based setup in silent mode.
Yes, it is.
Blair
-Original Message-
From: Dirk Kuypers [mailto:kuypers.d...@googlemail.com]
Sent: Tuesday, January 24, 2012 4:52 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installer hanging while doing FileCost - ID:
2951181
Hi,
2012/1/24
I have an installer that I wrote that I've been pushing out through SCCM.
We have deployed to about 600 servers so far and so far I've seen 6
failures. There are 3 of one failure mode and 3 of another.
1) C# DTF terminates with 1603
This one is wierd. It's a deferred CA that get's it's
Did you set the Protocol to netfx?
On Mon, Jan 23, 2012 at 7:14 PM, Romeo S. dfox.mxyzp...@gmail.com wrote:
Hi,
I'm testing my Boostrapper in a clean machine and I noticed that the
progress bar when installing .NET Framework does not move. It just stops at
40% while .NET is installing in
Found this:
http://www.dizzymonkeydesign.com/blog/misc/adding-and-customizing-dlgs-in-wix-3/
which does (almost) exactly what I want.
The only snag is having the checkbox at the bottom of the dialog to overcome
the problem of its having a grey background - it there a way to get the
1. I don't quite understand but if you can attach a picture to a bug that
definitely sounds wrong.
2. Yeah, that's a bug.
3. Very strange. I don't understand. Maybe the first bug will explain this.
4. There is a bug open that /layout doesn't work in the Wix36.exe right
now. That needs to be
I can't help but I have seen something similar to 1 - my DTF action is an
immediate action that just reads the registry and sets a property, 99% of the
time it is fine. The tracing all indicates it is ok but on exit it returns
value 3, no logs, exception or anything useful - run again and it is
I have noticed a weird scenario similar to 1). In my case, I'm using the IIs
custom actions in WiX 3.5. Sometimes the package fails with a 1603 error during
WriteIIs7ConfigChanges. Rerunning the package succeeds. The error information I
see in the log is always consistent and looks like this:
Bug 3479030 raised with image attached.
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 24 January 2012 16:47
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Install 3.6 on clean VM
1. I don't quite understand but if you can
On 24-Jan-12 10:02, Vadym Verba wrote:
I have a small but a very vital question: how to patch bundle?
Build a new bundle that contains the patches, either by themselves or
with the original packages.
--
sig://boB
http://joyofsetup.com/
On 24-Jan-12 07:14, Peter Bulyaki wrote:
So I would rephrase my question: is there a way to install a bundle without
registering it not only in Programs and Features, but in general with
Windoes Installer as a separate product?
Bundles aren't MSI products. They need to run (and therefore be the
On 24-Jan-12 05:11, scott.lang...@appsense.com wrote:
I invoked MSBuild with the build project command from within the VS2010 IDE.
The Sign* targets don't run by default. Set the SignOutput property to
true and call the Signing target.
--
sig://boB
http://joyofsetup.com/
That works, thanks.
I'm guessing this will also be applied in the WiX installer itself? As I
basically copied the Netfx.wxs in WiX source.
Cheers,
Romeo
--
View this message in context:
Hi,
I’m brand new to using WiX, just started yesterday!
I’m actually having trouble getting WiX installed and I’m clearly missing a
step somewhere. I have downloaded the 3.5 msi from
http://wix.codeplex.com/releases/view/60102
I ran that which seemed to complete Ok, at least I didn’t notice any
Candle.exe is not in your path by default. Either 1) add %WIX%\bin to your
path; or 2) run candle (and related utilities) using the full path of
%WIX%\bin\candle.exe candle_arguments_and switches. The environment variable
%WIX% is usually defined by the install. To check in your command
I posted a commented on your SF bug and figured I would post it here as well:
I couldn't view your attached image (I think it's corrupt) but I suspect
the problem might be the same issue I was seeing at one point with my own
experimental BA.
My issue was rooted in the fact that the engine
Neil,
I think you're spot on with what I'm seeing. My static method entry point
instantiates a class which then logs that it's been created and then
nothing. Run it again and it's fine. Here are some snippets from the
log:
PS- FWIW, I plan on making a fake MSI that just does some
Although I wrote this bug up for a different reason (
https://sourceforge.net/tracker/?func=detailaid=2013944group_id=105970atid=642714
https://sourceforge.net/tracker/?func=detailaid=2013944group_id=105970atid=642714
), if you read the comments you'll see that I was getting a similar issue. I
I read through that and yes I see a similarity. In my situation another
ManagedCA ( the part the does the costing and sets the CAD property ) ran
successfully. Then along comes the deferred CA and while it does start
executing it mysteriously dies.
Very interesting. And I'm sure Jason
Greetings
New to the community, please forgive me if I'm asking stupid questions.
Nevertheless, desperate times call for desperate measures, so here goes:
I've been working through the tutorial over at
http://wix.tramontana.co.hu/tutorial.
Are there any others out there (of equal
This is my log:
MSI (s) (D8:E8) [10:34:00:250]: Doing action: ReadSqlBinPath
Action 10:34:00: ReadSqlBinPath.
Action start 10:34:00: ReadSqlBinPath.
MSI (s) (D8:E8) [10:34:00:343]: Creating MSIHANDLE (31) of type 790542 for
thread 3048
MSI (s) (D8:B0) [10:34:00:421]: Invoking remote custom
There is a WiX book which may be of value WiX A Developers Guide to Windows
Installer XML
(http://www.amazon.com/WiX-Developers-Guide-Windows-Installer/dp/1849513724).
Bottom line with COM is write all registry entries directly with WiX code
rather than selfreg - it is hard work but pays off
I have a small utility that I find useful in registering COM. Basically it
puts a filesystem watcher on a directory and runs heat whenever it see's a
change.
Basically I drop a DLL/OCX into the directory and if I don't see COM
elements I open up depends and start copying in all of it's
I'm confused about best practices to use when deploying and maintaining
.NET *.config files via MSI. Our app uses the UnityContainer to manage type
injection and type configuration, some of which is environmental, meaning
type config changes at each customer site. This Unity configuration is
Sadly this is a huge huge hole / disconnect between how MSI works and how
XML works. MSI treats a Registry Value and File as atomic but an XML file
is not atomic. Elements, Attributes and Values are atomic.
The simplest way, assuming Unity can do this, is to layer your
configuration data
My suggestion is that you store this information in some soft of database and
have the application (or a configuration application ) manage the settings.
I think you'll find it difficult to be able to try and save / merge all this
data as time goes on.
--
View this message in context:
Yes, I think that bug is open already.
On Tue, Jan 24, 2012 at 10:51 AM, Romeo S. dfox.mxyzp...@gmail.com wrote:
That works, thanks.
I'm guessing this will also be applied in the WiX installer itself? As I
basically copied the Netfx.wxs in WiX source.
Cheers,
Romeo
--
View this message
Hi,
Yes, I think you are right, I got this when running the command you suggested:
MSI (s) (F8:34) [08:51:01:014]: SELMGR: ComponentId
'{9CD3A290-0DD5-4416-85D1-4781D9C8C0B6}' is registered to feature
'ProductFeature', but is not present in the Component table. Removal of
components from a
Hi again.
Take a look at this WixHarvest.targets file.
As far as I see I do pass the
HeatGenerateGuidsNowtrue/HeatGenerateGuidsNow... I thought that this should
keep the GUIDs consistent between builds... I'm wrong.
Project DefaultTargets=Build
49 matches
Mail list logo
