Hi everyone,
I would like to use WiX (with MSBuild) without running the WiX installer, but
by just copying the binaries to some location. Is this possible?
Background: We are using a NAnt script to build our projects, including the
installers. The idea is that we could just checkout the source
This should help you:
http://wix.sourceforge.net/manual-wix3/daily_builds.htm
http://wix.sourceforge.net/manual-wix3/daily_builds.htm-- Yan
On Tue, Jan 4, 2011 at 9:48 AM, Bosch, Andreas
andreas.bo...@swissray.comwrote:
Hi everyone,
I would like to use WiX (with MSBuild) without running the
On 21/12/2010 07:12, Neil Sleightholm wrote:
For more details about this take a look here
http://www.joyofsetup.com/2010/10/09/experimental-results-part-ii/
So far the result seem to indicate the not waiting for CostingComplete
doesn't have any effect.
I can't say I agree with that. I was
I recall having this problem when I did a wix 3.5 test. I think the new IIS
custom actions are scheduled after XML Config by default now.
Check the order in orca, I think you will need to schedule them later.
Dave
-Original Message-
From: Zhisheng Huang [mailto:zhhuang5...@yahoo.com]
Thanks a lot! Works perfectly.
Just as a sidenote: In addition to WixToolPath, WixTargetsPath, and
WixTasksPath, I also had to add a property WixExtDir which points to the
location of the WiX extensions like WixNetFxExtension.dll,
WixUIExtension.dll and so on... This might be related to the
There isn't a custom action in the WiX toolset that does this today. It'd
be cool if someone wanted to contribute it.
I did spend some time over the last week experimenting with the WiX 3.5 IIS
configuration feature. It looks promising but I could NOT figure out how
to
get it to set an MSI
Maybe. It's not really in the model Burn was designed for. Burn was intended
to provide a seamless installation experience not pop up a bunch of
different installation wizards.
Many years ago my wife got an iPod shuffle as a present. To use it we had to
install iTunes. The install was such a
Best way I've found to create SQL installs is to ensure all scripts are
idempotent. You want to be able to repair your MSI and have the scripts that
don't need to do anything not do anything and the scripts that find stuff
missing to recreate the missing stuff. Then, when you release next update,
I'd contribute it, if I could do it using DTF. :-)
Actually an interesting question in my mind... with Burn requiring .NET and
older operating systems being retired and newer operating systems coming with
at least .NET 2.0, at what point (if ever) will the WiX toolset have built in
custom
Rob,
That's an interesting comment but it makes me think of the Visual Studio
experience. It's a seamless experience installing a bunch of packages but the
result is the same. You pretty much have to reformat to get back to the
original state. Either that or run through lengthy
Thats perfect!! Everything is in place now.
Thanks so much for your guidance Blair :)
Keep up the good work of helping newbies like me :)
--
View this message in context:
Hi:
Interesting points, but given that the current ui has issues in the core market
this project is working in, (accessibility) this seemed like the obvious or at
least the quickest solution!
How does the current burn ui handle multiple features are they selectable, or
does it just install
Hello,
I have installed Windows Installer XML Toolset 3.5 on my development
machine, which is running Vista 32-bit, for what it's worth. I'm then
opening a .wixproj file using Visual Studio 2010 that was created by a
different developer here using WIX3.5/VS2010, I believe.
At any rate, when I
It looks like they have an older version of 3.5 installed than you do. I
believe it used to v3.5 but was later switched to use v3.x. If you both
install the same version it should solve your problem.
--
View this message in context:
Hello,
I looked at the other developer's add/remove programs, it showed the
same version as mine:
Windows Installer XML Toolset 3.5
Before the upgrade, I see:
$(MSBuildExtensionsPath)\Microsoft\WiX\v3.5\Wix2010.targets
In the .wixproj file, after the upgrade, I see:
All builds will say Windows Installer XML Toolset 3.5 but you need to check
the actual build version (I think the latest is 3.5.2430.0).
v3.x\Wix.targets is what is current
--
View this message in context:
I haven't worked with burn yet but from what I can tell it looks like you
would just set a burn variable to be passed to the MSI. So to install a set
a features you could just set the ADDLOCAL property as appropriate (in your
custom UI). You could also just split your large MSI into separate MSIs
Thanks, it looks like he has 3.5.1419, I have 3.5.2415.
On Tue, Jan 4, 2011 at 4:40 PM, jhennessey jack.hennes...@hyland.com wrote:
All builds will say Windows Installer XML Toolset 3.5 but you need to check
the actual build version (I think the latest is 3.5.2430.0).
v3.x\Wix.targets is
Hmmm, I'm on codeplex (http://wix.codeplex.com/releases/view/44406)
right now and I don't see a way to download 3.5.1419, is it possible
to do that? I checked out http://wixtoolset.org/ too, but it looks
like that's just a place-holder site for now.
-Eric
On Tue, Jan 4, 2011 at 5:03 PM, Eric
Thankyou Mike. Your solution worked like a charm.
Regards.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/OpeFileDialog-C-Custom-Action-tp5860149p5890363.html
Sent from the wix-users mailing list archive at Nabble.com.
1. If there are accessibility bugs in the wixstdba, we should work to fix
them. Please, feel free to file them. Sounds like you'd recognize them
quickly. smile/
2. Popping up multiple-MSI UI's is definitely not the easiest. I mean, we
could do it in Burn but it would not work well. You'd still
IMHO, the Visual Studio install is an absolute mess. I hope to get the
opportunity to really tackle some of the worst parts of the Visual Studio
install as part of my day job. The task is incredibly daunting so we'll see
what I'm allowed to do (and what the business prevents me from fixing).
You can also set conditions on Features directly. Or if you write your own
bootstrapper application, you can programmatically decide what to install on
the plan callbacks.
--
virtually, Rob Mensching - http://RobMensching.com LLC
On Tue, Jan 4, 2011 at 1:49 PM, jhennessey
Weekly release are at http://wix.sf.net/releases. Yes, I know, we need to
clean all this stuff up. Sorry.
Eventually http://wixtoolset.org will have all the information.
On Tue, Jan 4, 2011 at 2:14 PM, Eric Goforth eric.gofo...@gmail.com wrote:
Hmmm, I'm on codeplex
And to answer the actual question, I think 3.5.1419 has rolled off. That
build is almost a year out of date, we don't keep development builds around
for more than a few months typically (and less when we get to Escrow like
with WiX v3.5).
On Tue, Jan 4, 2011 at 11:30 PM, Rob Mensching
Yes, we switched to v3.x in hopes that the VS project system will not have
an upgrade in WiX v3.6 and later.
There were a great many changes in VS2010 that caused the project system
upgrade. It's painful and hopefully we've done the work necessary to not
need another one for the life of WiX v3.x
26 matches
Mail list logo
